Solution Scoping
Solution scoping is a fixed-price engagement that turns one idea, prototype, or audit finding into an architecture outline, a full decomposition of the work, and a signable proposal with a number attached. It typically takes one to three weeks. It is a fit when you know what you want built and need to know what it will actually cost.
A use-case analysis, an architecture outline, and a fully decomposed estimate. The plan and the proposal that come before anyone writes code.
Pricing Fixed price, quoted per engagement before scoping begins. See full pricing →
Why this service exists
Most projects are mispriced before they start, because nobody decomposed the work.
Scoping takes one idea (an audit finding, a working prototype, a partner brief, or a hunch someone has been carrying around for a year) and turns it into a plan with an architecture, a decomposition, and a number attached.
We break the work down into units small enough to estimate honestly, then flag the integrations, dependencies, and compliance constraints that normally surface halfway through a build. You get a phased roadmap and a proposal you can sign. If the scoping concludes you should not build it, that is a result worth paying for.
What’s Included
- ⌬ Use-case analysis and technical feasibility review
- ⌬ High-level architecture and integration outline
- ⌬ Full decomposition into estimable units of work
- ⌬ Risk, dependency, and compliance flags written down rather than implied
- ⌬ A phased roadmap with a recommended sequence
- ⌬ A formal proposal, ready for signature
One ask · four passes · nothing left to guess
How an ask gets decomposed into estimable units
The scope never changed size. Only our confidence in the number did.
Common Engagements
How this work usually shows up
Example scopes that turn this service into something tangible inside the business.
Audit Follow-Through
Engagement · 01
Take the ranked backlog an audit produced and turn the top one or two items into a delivery plan.
Solution Scoping
Prototype to Production
Engagement · 02
Assess what a working prototype actually needs to survive real users, real data, and real load.
Solution Scoping
Second Opinion
Engagement · 03
Pressure-test a scope or a quote you already have before you commit budget against it.
Solution Scoping
FAQ
Solution Scoping questions
The questions that come up most on intro calls, answered before you have to ask.
What is included in a fixed-price solution scope?
A MagicPill Labs solution scope includes a use-case analysis and feasibility review, a high-level architecture and integration outline, a full decomposition of the work into estimable units, written risk, dependency, and compliance flags, a phased roadmap, and a formal proposal ready for signature. The decomposition is the part that matters most: it is what makes the resulting quote defensible instead of a guess.
How is solution scoping different from an AI opportunity audit?
An audit looks across the whole business and asks what is worth building; scoping takes one idea and asks what it will actually take to build. The audit's output is a ranked shortlist; the scope's output is an architecture, a decomposition, and a signable proposal for a single initiative. Companies that already know what they want to build usually skip the audit and start at scoping.
What happens if the scope changes mid-build?
Scope changes are re-estimated against the same decomposition the original quote was built from, so a change is priced in the same units as the rest of the work rather than absorbed as an unpriced extra. Because work is broken into small units, most changes affect a handful of them, and you see the cost of a change before it is accepted, not on the next invoice.
Can we take the scope to another developer?
Yes. The scoping deliverable is written to be executable by anyone: the architecture outline, the decomposition, and the risk flags are vendor-neutral, and companies regularly use a MagicPill Labs scope to solicit competing bids or to brief an internal team. Scoping is priced as a standalone product for exactly that reason.
What if the scoping concludes we should not build it?
That is a valid and reasonably common outcome, and it is delivered as a written finding with the reasoning behind it. A scope that ends in "do not build this, here is the cheaper thing that solves the same problem" costs a fraction of a failed build, which is the point of pricing scoping separately from delivery.