Software Yard / Capability 06Scope / Delivery / Technology fit

Rapid
prototypes.

Learn before the big build.

Build enough to answer the important question before committing to the whole product.

We create focused prototypes and proof-of-concept builds to test workflows, product direction and technical feasibility without pretending an experiment is production software.

Start a prototype Explore related work
From question to evidence
01 / question

The assumption or uncertainty being tested.

The starting point

When the biggest risk is still an assumption.

Some ideas should not begin with a full production build. A prototype creates a controlled way to test the workflow, interaction or technical assumption that could change the entire direction.

Sound familiar?
  1. 01

    A new product idea needs something tangible before a larger investment.

  2. 02

    A difficult workflow needs to be tested with real users.

  3. 03

    A technical integration or concept needs a feasibility check.

  4. 04

    The team is debating multiple product directions without enough evidence.

  5. 05

    A stakeholder needs to understand the product through interaction rather than slides.

  6. 06

    A risky feature should be isolated before being introduced into an existing product.

The scope

One important question. A focused build.

Choose the smallest credible experiment, not a smaller version of the entire roadmap.

01

Clickable product prototypes

Interactive product flows for testing structure, behavior and user understanding.

02

Functional proof-of-concepts

Small working systems built to test a technical assumption rather than simulate it.

03

Workflow prototypes

Focused representations of high-friction business or customer processes before full implementation.

04

Integration spikes

Time-bounded technical experiments to learn whether an external service or interface is viable.

05

MVP slices

One coherent product slice built deeply enough to validate the core loop without building the entire roadmap.

06

Experimental interfaces

New interaction patterns tested as isolated product experiments before being committed to production.

What you leave with

A prototype that answers a question.

The purpose of a prototype is learning. Scope, fidelity and technical depth are chosen around the uncertainty that needs to be reduced.

How Software Yard works
Rapid Prototypes / Delivery outline
  1. 01Testable product direction
  2. 02Reduced technical uncertainty
  3. 03Working proof-of-concept
  4. 04Clear next-step decision
  5. 05Reusable learning
  6. 06Defined production gaps

Your agreed scope defines the final deliverables.

A focused approach

Reduce the uncertainty, not the standard.

The wider Software Yard method
  1. 01

    QUESTION

    Define exactly what the prototype needs to prove, disprove or clarify.

  2. 02

    CUT

    Remove everything that does not contribute to answering that question.

  3. 03

    BUILD

    Create the smallest credible interaction or technical slice needed for the test.

  4. 04

    TEST

    Put the prototype against the workflow, stakeholder or technical constraint it was built for.

  5. 05

    LEARN

    Record what changed, what held up and what remains uncertain.

  6. 06

    DECIDE

    Use the evidence to stop, iterate or move toward a production build.

Technology fit

The right foundation.
Not a fixed formula.

The final stack depends on the product, constraints and existing systems. These are tools relevant to this capability, not a requirement to use them all.

  • TypeScript
  • Python
  • Next.js
  • Supabase
  • SQLite
  • Vercel
Explore the technology landscape Read the engineering standard
Related work

Work from the Yard.
Relevant to the brief.

Explore the public stories behind relevant work from the Yard.

The standard behind the work
A prototype should answer a question, not pretend to be a finished product.
Junkyard Mind / Software Yard
Before we build

Good questions.
Clear answers.

01Is a prototype production-ready?

Not automatically. The page and engagement should make clear which parts are experimental and what would be required for production.

02How much of the product do you prototype?

Only enough to answer the agreed question. Building the entire roadmap defeats the purpose of a focused prototype.

03Can prototypes include real integrations?

Yes, when technical feasibility is the question being tested and suitable access is available.

04Can a prototype become the foundation of the real product?

Sometimes, but only after reviewing what should be hardened, replaced or redesigned for production.

05Do you prototype mobile experiences?

Yes. Web or mobile prototypes can be appropriate depending on the interaction being tested.

06What happens after the prototype?

The result should support a decision: stop, revise the idea, run another experiment or move into a production build.

HAVE SOMETHING THAT NEEDS TO BE TESTED?

Find out
what holds up.

Bring us the assumption, the risky workflow or the idea that needs evidence before a bigger build.

Start a prototype