Skip to Content
VALIDATE / PRODUCT FEASIBILITY

Know if it's worth building — before you build.

STUDIO
Configure this and see your price.
Open the Studio →

Product Feasibility answers one question before you commit an engineering budget: should this be built, and can it be sold? It is for teams holding an idea, a deadline and no evidence strong enough to defend either answer.

Services / Product Feasibility — Market to Motion
WHAT IT IS

The cheapest way to avoid the most expensive mistake.

Market to Motion takes one product idea and tests it in four directions: who already serves the need and what they charge, what the riskiest technical part costs to prove, what the build costs in money and months, and how the product reaches its first buyers. Both tracks, because an idea that can be built but cannot be sold fails just as expensively as one that cannot be built.

The investigation is run by the people who build. We write code during feasibility — a narrow spike against the riskiest assumption, not a slide about it. If the idea depends on an integration, a data source, a model or a latency budget, we go and touch it instead of estimating around it. The cost numbers come from shipping and running our own products — EVERJUST.APP, CustomAgents and Custom Domain — not from a rate card.

You end with a written recommendation: build, do not build, or build something smaller first. Every assumption behind it is named, so you can argue with one line of the reasoning rather than the conclusion as a whole.

HOW IT RUNS

How the sprint runs.

01 · FRAME

Scope lock

one working session to fix the decision being made, the constraints around it, and what evidence would genuinely change your mind. The price and the working window are set here, before work starts.

02 · TEST

Market and motion read

who already solves this, what they charge, what people use instead, and where a new entrant has room. Then the harder half: who buys first, and through which channel.

03 · PRICE

Technical probe

we build a throwaway spike against the single riskiest assumption and record what broke, what held, and what it cost to find out.

04 · RECOMMEND

Cost envelope and call

the build priced in three bands, the monthly cost of running it, and the recommendation with its reasoning attached.

WHAT YOU GET

Concrete deliverables.

You receive

  • A feasibility report with the build / do-not-build call on page one and the reasoning in the pages after.
  • A market map: named competitors and substitutes, their pricing, and the gaps we think are real.
  • A first-motion note: who buys first, where they already are, and the one channel we would test before any other.
  • A ranked technical risk register, each risk priced by what it costs you if it turns out to be true.

And also

  • A reference architecture sketch: services, data flow, third-party dependencies, and the build-versus-buy calls.
  • A cost envelope — lean, expected and heavy build estimates, plus the monthly cost of running the product once it exists.
  • The spike repository, pushed to your Git organisation, with the code we wrote to test the riskiest assumption.
  • A recorded walkthrough, so the people who were not in the room hear the argument rather than a summary of it.
FIT

Who this is for — and who it is not.

A good fit when

  • A budget decision is coming and nothing in the room is strong enough to defend either answer.
  • The idea rests on something unproven — an integration, a model, a data source, a performance ceiling.
  • You hold build quotes that differ by an order of magnitude and no way to tell which one is honest.

Not the right call when

  • You have already decided to build and want a document that agrees with you. Do not build is a real output here.
  • You want the market half without the spike. We do not sell the paper on its own; the code is where the answer usually changes.
  • The hard question is legal or regulatory rather than commercial or technical. That needs counsel, not us.
  • You already know the idea works and only need it made. Start at Product Development — Enterprise Build, from $25,000.
FAQ

Good questions.

Why "from $3,500"?

$3,500 covers one product idea, one market, one technical spike. The number moves up when the scope does — several markets, a regulated sector, multiple integrations to probe, or a spike that needs real infrastructure to run. We agree it at scope lock, before work starts.

How long does it take?

The technical probe sets the length. A spike against a documented public API is quick; a spike against an undocumented internal system is not. We fix the working window with you at scope lock rather than quoting one blind.

Who owns the output?

You do. Report, architecture sketch, cost model and spike repository are yours at handover, with no licence retained by us. The spike code is deliberately throwaway — it answers a question, it does not become your codebase — but it is yours to keep, extend or delete.

What happens after?

If the answer is build, the cost envelope becomes the scope for Product Development — Enterprise Build, from $25,000. If adoption is the harder problem, the GTM — Growth Loop Program runs at $5,000 per month, flat. If the answer is do not build, the engagement ends there, and it has done its job.

PRICING
From $3,500 / fixed scope

Pressure-test it first.

A fixed-scope investigation that ends in a build or do-not-build recommendation, with the reasoning shown.

Start a feasibility sprint ↗