Diagnosis
Diagnosis is a paid engagement from Make It Happen, a software studio, that interrogates how your business actually runs before anyone writes code. We map the current process, research your market, challenge the brief, and separate what is impossible from what is only hard.
Something is wrong and nobody can name it
Before a line of code is written, we tell you which part is impossible — there is always one — and which part is only hard. That is always the rest.
What it solves
You know something is broken and you cannot say what. Work leaks somewhere between the first call and the delivery, the last three proposals for fixing it disagreed with each other, and none explained why.
A brief that describes a symptom gets built, and the symptom moves. We take the brief apart instead of accepting it: structured interrogation of how the work actually runs, not a questionnaire your operations lead fills in alone.
Most studios scope what you asked for. We scope what will work, and when the two differ we say so in writing — including the part we think should not be built at all, by us or by anyone.
What you get
Before a line of code is written, we tell you which part is impossible — there is always one — and which part is only hard. That is always the rest.
No code. A diagnosis ends in findings, a prioritized map and a plan; building any of it is a separate decision you make after you read it.
We do not audit your existing code line by line. The diagnosis reads the process, the market and the brief; a full technical review of a system you already run is scoped separately.
No promise that the answer is software. Some diagnoses end in a process change or a decision to stop doing something, and we write that down instead of proposing a build.
What changes
A brief written from a symptom and a deadline.
A brief that names the cause, the constraint and the order of work.
Nobody will say out loud which part will not work.
The impossible part is on page one, with the reason.
Who this fits
Companies of roughly 10 to 200 employees where the process lives in several heads and nobody holds the whole map.
You are about to commission a build, or the last one failed and you do not want to repeat the brief that caused it.
1 week to a documented diagnosis
Whoever runs the process sits with us, not only whoever signs. Week one is interviews, a walk through the real workflow, and the first findings read back to you for correction.
Every engagement, same nine stages
Nine stages, in order, each one handing over a document the next one reads. It is the same sequence whatever is being built, which is why we can tell you where your project is on any day of the week.
Questions buyers actually ask
What do I get out of a diagnosis before I commit to a build?
A documented diagnosis: findings ranked by what they are costing you in time and risk, a map of the openings we found, and — if you decide to continue — a full plan with staged options. The document is yours to take to anyone, including another studio.
How long does a diagnosis take?
One week to a documented diagnosis. Most of that week is interviews and reading how the work really moves — orders, handoffs, exceptions. We compress it by interrogating a narrow set of people who do the work daily rather than surveying everyone who has an opinion.
Can you just build what I already specified?
We can, after we tell you where the specification will break. If the analysis says your spec works, we say that in one page and start. If it says part of it cannot work, you get the reason and the alternative before anything is committed to code.
Do I have to build with you afterwards?
No. The diagnosis stands alone and the document is written to be legible to any competent engineer, not only to us. Some take the plan in house, some take it to a second studio, some continue with us. The findings do not expire while you decide.
What if the diagnosis says the project is not worth doing?
Then that is the finding, and we write it with the reasoning that got us there. Stopping early is the best outcome available on a bad premise, and the one most studios will not sell. We would rather lose the build than deliver something we already told you would not hold.
The possible part of the impossible.
If you have an idea that shouldn't work, bring it. We will tell you which part is genuinely impossible and which part is only hard. Most of it is the second one.