Approach
How we decide what to build.
Most software is lost before it is written: the wrong problem, the wrong boundary, a data model that cannot carry the business as it grows. We spend the first phase on those decisions, and we write them down.
The system comes first
Architecture is a business decision.
A system is a set of agreements: what a customer is, what an order means, which record wins when two disagree, who is allowed to reverse a decision. Those agreements outlive every framework we might choose. When they are wrong, no amount of clean code rescues the product.
So we ask uncomfortable questions early. What happens when the payment provider is unavailable for an hour? What does the warehouse team do when the stock count is wrong? Who reviews an automated decision, and what do they see on screen? A build that skips these questions does not avoid them. It postpones them to a worse moment, usually the week after launch.
The output of that work is short and unglamorous: a written architecture, a scope, a list of risks and a number. You can take it to another team, or to your board, without asking our permission.
What we look for before we start
- A problem that someone in the business owns, with the authority to change it.
- Access to the people who do the work today, not only the people who sponsor it.
- A deadline you can name, even if it is uncomfortable.
- Permission to change the process, not just the software around it.
Fit
Where a model helps, and where it gets in the way.
Most disappointing projects apply the technology to a problem that cannot hold it.
Worth building
- Reading and routing documents
- Invoices, claims, applications. High volume, consistent format, a person checking exceptions.
- Search across your own material
- Contracts, policies, support history. The answer has to cite the passage it came from.
- Drafting a first version
- Proposals, replies, summaries. A person edits, and nothing leaves the building without review.
- First-line support
- Repetitive questions with known answers, and escalation rules that stay explicit.
Better solved another way
- Decisions with money or safety attached
- Pricing exceptions, credit, clinical or legal judgement. A person decides, and signs their name.
- Problems nobody can score
- If the team cannot describe a good answer, there is no way to know whether the system works.
- Anything that must repeat exactly
- Deterministic rules belong in code, where they can be tested and audited line by line.
- Data you would not show a new hire
- Permission problems are not solved by a prompt, and access is not a feature we can add later.
Three layers
Designed together, or not at all.
A working system needs all three. Most projects build one and hope the others follow.
Model
Chosen against a sample of your real work, not a demo dataset. Evaluated on the cases your team already knows are hard, and replaced without a rewrite when something better arrives.
- Model selection and cost modelling
- Evaluation set with known answers
- Fallback for outages and refusals
Workflow
Decides what happens next: queue, retry, review, escalate. Every automated path has an owner, a record, and a switch that turns it off without taking the system down.
- Review queues and escalation
- Audit trail per decision
- Kill switch and rollback
Interface
Shows the work and its provenance. Sources, confidence and edit history are visible, and the screen never pretends to know more than the system does.
- Citations and confidence cues
- Editable output, kept as a draft
- Empty and failure states written first
Rules
Five rules we apply to every build.
Working constraints, not values on a wall: five rules applied to every build.
No decision without a reviewer
If a person cannot inspect an automated decision and reverse it, that decision does not go live. The reviewer sees the input, the reasoning and the record.
Evaluation before launch
A set of cases with known correct answers, written with your team, run on every change. If the score drops, the release stops.
Data before models
If the source records disagree, the first work is reconciliation. A better model over inconsistent data produces confident nonsense.
A fallback that has run
A path that has never been exercised in production is not a fallback. We test the failure case on purpose, during working hours.
Cost is a design constraint
Token cost and latency decide which approaches are viable. We model both before choosing, so the system is still affordable at ten times the volume.