Find the real requirement
What has to be true for this to be worth doing, and what is currently just assumed.
guest@make-directory:~$ cat ./solutions/build-launch.md
make-directory:~/solutions/build-launch
Turn an idea into something people can actually use.
From ambiguity to a working production system. We take requirements, opportunities, and half-formed ideas and turn them into software that is real, usable, maintainable, and owned.
guest@make-directory:~$ cat ./sound-familiar.md
the situation
Everyone agrees it should exist. What nobody can say is what it would take, what it should be built on, or what the first usable version looks like. So it stays a document, or it starts and stalls halfway.
There is a clear business case and no technical plan
You have an estimate you have no way to evaluate
A previous attempt stalled and you are wary of starting again
The requirements keep growing every time they are discussed
You are not sure whether to buy something or build it
The idea depends on systems you already run
guest@make-directory:~$ cat ./what-changes.md
the outcome
A working production system, maintainable after launch and owned by someone.
- A first version that is genuinely usable, not a demo
- Scope that got smaller during planning rather than larger during build
- Architecture chosen for what this actually needs, not for what is fashionable
- A codebase your team or ours can keep changing
- A launch with monitoring, and a plan for the week after
guest@make-directory:~$ cat ./how-we-approach-it.md
how we approach it
What the work actually looks like.
Cut it down
The first release should be the smallest thing that is genuinely useful. Most of the value of planning is what it removes.
Build in working increments
Something running early and often, with the tradeoffs visible while they are still cheap to change.
Launch and keep going
Monitoring, a real support path, and the second release planned before the first one lands.
guest@make-directory:~$ ls ./what-it-might-be
what this could become
What it turns out to be depends on what we find.
Here is what this work has become for other people, so you can get a feel for the range. Which one fits your situation is something we work out together, once we understand it.
- A customer portal, when people outside need a way in
- An internal application, when the work does not fit off-the-shelf software
- A mobile app, when the workflow happens away from a desk
- A SaaS product, when the thing you built for yourself has a market
- An integration or a dashboard, when the need is smaller than it first looked
- Sometimes: configuring something that already exists, and saving the build
guest@make-directory:~$ cat ./proof.md
work we can show you
Something we built and operate
Strata models cloud infrastructure across AWS, Google Cloud, and Azure as a typed graph, imports live state and infrastructure-as-code, and runs validation, reachability, cost, and migration engines shared between a UI and an MCP server. Open source, and you can read the code.
Take a lookguest@make-directory:~$ cat ./where-this-goes.md
where it usually goes
Usually Growth or Partner.
New builds usually open with an assessment or a scoping engagement, then run as Growth or Partner depending on whether someone internal is owning the product decisions.
guest@make-directory:~$ ls ./related-reading
related reading
How we think about this.
How to Scope a Web App Before You Ask for an Estimate
A practical way to prepare for a web app estimate by clarifying users, workflows, data, integrations, and launch priorities.
Why Discovery Matters Before a Software ProjectDiscovery helps teams understand scope, risk, users, systems, and priorities before committing to a larger software build.
An Introduction to User Stories: thinking from a user's perspectiveSo what are user stories anyway? Detailed plans often go unread. With little time to review specific and intimidating plans, workers often start projects first and...
guest@make-directory:~$ cat ./faq.md
questions
Frequently asked questions
How do we know what it will cost before we start?
You do not, precisely, and neither does anyone who tells you otherwise. What you can have is a scoped first phase with a fixed price, an honest range for what follows, and the option to stop at each phase boundary.
Should we build or buy?
Buy, if something exists that fits. We have talked clients out of builds when configuring an existing product would do — it is a shorter engagement for us and a much better outcome for them.
What technology will you use?
Whatever fits the problem and can be maintained afterwards. That is usually a boring, well-supported stack rather than an interesting one, and the decision comes after the requirements rather than before.
What happens after launch?
Software that launches and then stops being maintained decays quickly. Most builds continue as an ongoing tier — but if you would rather take it in-house, we document and hand over properly.
guest@make-directory:~$ mkdir ./what-needs-to-change
next step
Tell us what is not working.
A few sentences about your situation is plenty to start with. We will come back with what we think it takes, and say so if we are the wrong people for it.
Not sure this is the right one?
These four overlap, and most real situations are a mix of them. An assessment sorts out which parts matter and in what order, and you keep the write-up either way.
Start an Assessment