How we build
Define, prototype, build, ship, learn.
If a development process needs a diagram to explain it, it is not being followed. Ours fits on one line. Each stage has a single rule, and the rule is what settles arguments when the schedule gets tight.
The process
Five stages. The order matters more than the names — most failed projects we have seen skipped the second one.
- 01
Define
Narrow the problem until it fits in one sentence.
Most software failures are scoping failures wearing a technical costume. Before anything is designed we get to a single sentence describing who has the problem, what it costs them, and how we will know it is solved. If that sentence needs an 'and', it is two projects. This stage ends when the sentence survives a hostile reading.
What comes out of it
- A one-sentence problem statement
- The specific decision or task the software has to improve
- What we are explicitly not building
- 02
Prototype
Build the risky part first, never the easy part.
There is a strong pull toward starting with whatever is pleasant to build — the sign-up screen, the settings page, the marketing site. That work is comfortable precisely because it holds no uncertainty. We start at the part most likely to be wrong: the integration nobody has read the documentation for, the model whose accuracy is unproven, the workflow nobody has watched a real person perform. Finding out early is the entire value of the stage.
What comes out of it
- A working slice of the hardest thing
- A written list of what we now know that we did not before
- A revised estimate, or a recommendation not to proceed
- 03
Build
Typed end to end, tested by consequence, observable before scale.
Types run from the database to the interface so that a change to a shape breaks the build rather than a user's afternoon. Tests are weighted by what failure costs — money movement, permissions, and data deletion get heavy coverage; a settings toggle does not. Logging, error tracking, and the metrics that matter go in while the system is small, because instrumenting a system under load is a different and worse project.
What comes out of it
- Type safety across the boundary between server and client
- Tests concentrated where failure is expensive
- Error tracking and structured logs from the first deploy
- An admin surface for the team that has to support it
- 04
Ship
Real releases, on a fixed cadence, to real users.
Release dates that move teach a team that dates do not matter. We hold the cadence and move the scope instead, which forces the prioritisation conversation to happen early and out loud rather than in the final week. Every release goes out behind whatever flag or staged rollout the risk justifies, and every release is something a user could actually notice.
What comes out of it
- A predictable release rhythm
- Staged rollout and a rehearsed way back
- Release notes written for users, not for the changelog
- 05
Learn
Instrument, then simplify. Most good releases remove something.
After launch the question stops being what to add and becomes what is not being used. Features that nobody touches are not free — they are a tax on every subsequent change, and they make the product harder to understand for the people who do use it. We look at what the data says is dead, confirm it is really dead, and take it out. Products that stay good stay small on purpose.
What comes out of it
- Usage data against the original problem statement
- A list of candidates for removal
- The next single sentence
Engineering standards
What we hold to, whatever the project is.
These are not negotiated per engagement. They are the reason our estimates look the way they do, and the reason the second year of a codebase costs about what the first one did.
Type safety end to end
Types cross every boundary — database, server, client. The compiler should be the first reviewer, and a shape change should break a build rather than surface as a support ticket three weeks later.
Tests weighted by consequence
Coverage percentage is a number that can be raised without making anything safer. We test heavily where failure costs money, leaks data, or cannot be undone, and lightly where it costs a reload.
Observability before scale
Structured logs, error tracking, and the two or three metrics that actually describe health go in from the first deploy. Adding them to a system already under load is a rescue operation.
Accessibility as a build requirement
Keyboard operation, focus order, contrast, and labelling are part of the definition of done, not an audit that happens after launch and generates a backlog nobody schedules.
Explicit performance budgets
A page weight and an interaction latency, agreed in advance and checked in CI. Performance defended continuously stays; performance recovered in a sprint comes back next quarter.
Documentation that survives us
Architecture decisions get written down with their reasoning, because the expensive question later is never what the code does but why it was done that way.
Ways to work together
Three shapes, depending on where you are.
Most work starts with the first one, including work that later becomes the third. We would rather be certain about the problem before either of us commits to a build.
Start a conversationDiscovery sprint
Fixed scope, fixed feeA short, bounded engagement that ends in a written recommendation: the problem statement, the risky parts, a technical approach, and an honest estimate. Sometimes the recommendation is not to build it. That outcome is worth the fee too.
Fits when: You have a problem and competing opinions about the solution.
Build partnership
Milestone-basedWe design and build the product with you, working in the release cadence described above. You get the code, the infrastructure, and the documentation throughout — not as a handover event at the end.
Fits when: You know what needs building and need a team that will finish it.
Product ownership
OngoingWe build and operate the product: releases, monitoring, support tooling, and the roadmap. This is how we run our own products, applied to yours.
Fits when: You need the product to exist and run, without hiring a team to do it.
Discovery
Most good projects start with a hard question.
Send us the problem rather than the specification. If a discovery sprint is the right next step we will say so, and if we think you should not build the thing at all we will say that too.
Contact the dock
One address, read by the people who would do the work. No intake form, no calendar link — just an email.
tphamdn@gmail.com