Fix the constraint before you fund the experiment.
We put most of the effort into the workflow that already controls revenue or capacity, then earn the right to expand.
70%
Fix the core flow
Start where work, information, or demand is already getting stuck. For a machine shop, that means pipeline, quoting, scheduling, job visibility, and the handoffs that keep machines loaded.
We look for work with a credible 3-to-6-month payback target. That is a selection rule, not a guarantee.
20%
Extend what is working
Once the core flow is visible and stable, connect adjacent systems or build the missing layer that off-the-shelf tools cannot cover.
These projects can take longer to prove because they depend on the core process being adopted first.
10%
Test a future bet
Use a small slice of the budget for a bounded experiment. Define the learning goal, cap the downside, and stop if the result does not support a larger build.
Experiments are judged by evidence and a go-or-stop decision, not by a promised return.
What owners say after the work ships.
“Before Light in the Dark Analytics, the entire business ran on four whiteboards and whatever was in the previous owner's head. Bringing them in was the best decision we made in the whole hold.”
“Having a team that's this customer-centric is very rare. Working with Light in the Dark Analytics is the reason VetMyRoof exists today.”
The questions you should ask before a build.
Risk, security, adoption, capacity, and control should be answered before a proposal, not after a problem.
Is our data safe?+
The answer depends on the architecture. A browser-local tool can keep data on the device. A hosted workflow may send only defined fields to approved systems. We document the boundary and do not claim that nothing leaves your systems unless the implementation actually guarantees it.
Do you have SOC 2?+
Light in the Dark Analytics is not SOC 2 certified today. We will not imply otherwise. If your procurement policy requires it, we determine whether an architecture built entirely on vendors you already approve is acceptable. If it is not, we are not the right fit yet.
What if the project does not work?+
The scope, milestones, acceptance criteria, and engagement-specific terms are written down before work begins. We do not advertise a blanket outcome guarantee. If the operating math or adoption plan does not support the project, the right decision is not to start it.
Will this replace our people?+
That is not the manufacturing case. Cutting people does not load a machine. The goal is more throughput through the same building by giving the existing crew clearer information and removing stalls.
We need to finish current work, not generate more leads.+
Then flow comes first. We fix visibility, handoffs, and scheduling before adding demand. Pipeline work waits until the floor can absorb it. The 70-20-10 method follows the real constraint, even when that means delaying a service we could sell.
How long until we see a result?+
It depends on the constraint and adoption. Lamb's Machine Works went four months from systems-live to rapid growth. VetMyRoof went one month from kickoff to a live web app. Those are real timelines, not promises for a different operation.
We tried AI already and it went nowhere.+
That usually means the experiment started with an impressive use case instead of a costly operating problem. The 70-20-10 method puts most of the effort into proven core constraints, a smaller share into adjacent opportunities, and only 10% into bounded experiments.
Will we lose visibility into our own business?+
Systems that run without constant intervention should not run without oversight. A shared source of truth, clear ownership, and useful dashboards give the owner more visibility while removing the need to relay every update.
Let's talk.
30 minutes. No pitch. No pressure. We'll ask questions, listen to how things work, and tell you honestly whether there's something worth fixing.