Most partners I talk to have a reasonable question the first time they hear how Brightline engagements work. What actually happens during a two-week sprint? The timeline sounds compressed. The price sounds low. If the work were really that straightforward, the question goes, wouldn’t every firm have already done it?
The answer is that the work is straightforward, when you do it this way. The reason most firms have not already done it is that most development shops don’t operate this way. They sell multi-month platforms, not two-week modules. They build from scratch, not from firm context. They have not internalized that an experienced engineer working with modern AI tooling produces, in ten days, roughly what a traditional team produced in three months of 2019.
Here is what actually happens, day by day, in a representative engagement.
Day 0: The discovery call
Before any work starts, we have a 30-minute call. I ask three questions:
- What workflow, specifically, eats the most time in your firm?
- Who is the person inside your firm who knows how that workflow actually works? Not the person in charge of it. The person who does it.
- If that workflow was 80% faster, what would your firm do with the reclaimed hours?
If the answers don’t produce a candidate workflow that meets the criteria for a good first module, I say so. Roughly one in five discovery calls ends with me telling the partner that what they actually need is to renegotiate a vendor contract or reorganize a team, not build software. That is a successful discovery call.
Day 1: Scoping document and sample data
Assuming the call lands on a real build candidate, the first work product is a one-page scoping document. It names the workflow, the single measurable outcome the module will improve (turnaround time, hours per engagement, review cycles), the inputs the module will see, and the outputs it will produce. It also names what the module will explicitly not do.
That last part is the most important. Scope creep is the single largest reason custom software engagements fail. A one-page scope with three explicit non-goals is better insurance against a failed project than any SOW section on change management.
The firm sends, under NDA, five to twenty sample files that represent the workflow. Real matters, real engagements, real data. Redacted where privilege or compliance requires it, but otherwise authentic.
Days 2 to 3: The skeleton build
With scope in hand, the first two build days produce a working skeleton. This is not a prototype in the old sense. It is a functional pipeline: inputs come in, the model runs, outputs come out. It is ugly. The outputs are wrong in places. The interface is a command line.
The point is not polish. The point is to have something runnable against real data, so the next three days can be spent tuning the behavior to match the firm’s actual standards.
The architecture is deliberately boring. TypeScript or Python backend. Postgres or whatever the firm already uses. A small React front end if there is a user-facing surface at all. No novel frameworks, no exotic vector databases, no infrastructure that requires a specialist to maintain. A module a reasonable developer can read and understand in an afternoon.
Days 4 to 6: Calibration against firm standards
This is where most of the value is produced. I sit with the person the managing partner named on the discovery call: the paralegal who actually runs discovery triage, the senior associate who does workpaper review, the intake coordinator who converts referrals into matters.
We run the module against 20 to 40 real cases. We look at the outputs together. They tell me what’s wrong, what’s close, what the firm actually cares about that the module isn’t surfacing. I adjust the prompts, the extraction logic, the output format. We run it again.
By the end of day 6, the module is producing output that the senior reviewer would accept with minor edits 85 to 90% of the time. That is the target. If it were 100%, the firm would be right to worry about what the model was hallucinating to get there.
Day 7: Integration
On day 7, the module stops being a script and becomes a tool the firm can actually use. This means integration with whatever the firm already has: document management system, practice management platform, email, Slack, a SharePoint folder, sometimes just a shared drive. We avoid adding new interfaces unless the firm specifically wants one.
The pattern that works best is to put the module behind whatever the team already uses. An email inbox that triggers the module on incoming files. A Slack command that summarizes a matter. A new button in the existing document management UI. New tools get abandoned. Enhancements to existing tools get adopted.
Day 8: Review session and hardening
Full run-through with the partner or managing partner who sponsored the engagement. They see the module work on real files. They sign off or they send me back for specific adjustments. This is also when we harden the module against failure: what happens if the model is down, what happens if the input file is malformed, what happens if a user uploads a file that is not what the module expects.
These questions sound boring. They are the entire difference between a tool the firm uses for six months and a tool the firm uses for six years.
Day 9: Documentation and handoff prep
Documentation happens last, because it can. The firm receives:
- A README aimed at a competent developer who may need to maintain the module in two years.
- A short operator guide aimed at the day-to-day user. Usually four to six pages.
- A decision log: every non-obvious architectural choice and why it was made.
- A list of the 5 to 10 ways the module could be extended in the future, with honest estimates of effort for each.
Day 10: Handoff
The source code is pushed to a GitHub repository the firm owns. The deployment runs on infrastructure the firm controls: a dedicated project in the firm’s cloud account, the firm’s LLM provider contract. I get removed from the repository’s admin list at the end of the handoff call. A competent developer at the firm, or any developer the firm wants to hire, can take it from there.
The engagement ends. If the firm never calls me again, that is a successful engagement. Some firms sign on for a lightweight monthly retainer. Most don’t, because they don’t need to. The module was built boringly on purpose.
What this actually replaces
Compared to the traditional alternative, a 12-month platform engagement with an enterprise consultancy, this is a different category of engagement. The scope is narrower. The price is lower by one or two orders of magnitude. The outcome is a tool the firm owns outright, built exactly for the firm’s workflow, by someone who spent two weeks living inside the workflow to build it.
This is not the only way to build custom software. It is the only way that makes sense for a 10-to-50-person professional-services firm that wants to own its operational advantage instead of renting someone else’s.
If you’ve read this far and a candidate workflow is already forming in your head, that is usually a good sign. The right first module is almost always the one that jumped to mind on the first paragraph.
