Most agencies sell discovery, then a deck, then a spec, then a build, then a handover. Each step waits on the previous one. The FluxCo Method collapses discovery and prototyping into a single working session: real users in the room, code shipped to a real URL on day one. The deliverable from session one is software, not a document. Validation, prototyping, and production are phases on the same codebase, not three separate engagements.
How we work · The FluxCo Method
Validate, prototype, production.
One operating principle: put a working thing in front of a real user, then ship it. Three phases on one codebase, so nothing gets rebuilt at the end.
The principle
Validate then ship. A working thing in front of a real user beats a written spec in front of a stakeholder, every time. AI-assisted development compresses the loop from weeks to hours, which is what lets this run at the speed it does. Each phase feeds the next: Validate produces what to build, Prototype proves that the idea works, Production hardens it for daily use.
Same repository, same architecture, same URL throughout. We write production-shaped code from session one, not because we know the spec, but because we know we are not rewriting later.
Phase 1 — Validate
Sit with the people who will actually use the software. Watch the workflow as it exists today. Find what only software can fix.
1
Real users in the room. Not a manager, not a sponsor — the people who do the work today. End users describe problems differently than the people approving the budget. We need both, but the work starts with users.
2
Map the workflow before the solution. What does the day-to-day look like? Where does it break? What gets done on paper, in a spreadsheet, or in someone's head? The problem statement comes out of the conversation, not out of a document we wrote in advance.
3
Define success in one paragraph. Not a 12-point KPI list. One paragraph describing what the world looks like when this works, and a single test we can run later to know if we got there.
Output
Problem statement
One paragraph plus explicit success criteria
Duration
1–5 days
Depends on how scattered the user base is
From you
Access
Real users for one working session, plus example data
Phase 2 — Prototype
A working demo on a real URL, against real data, within days. Iterate with users while the problem is still fresh.
1
Live URL from session one. Not Figma, not a sandbox, a real deployed URL the user can open on their own machine. The first version exists in hours, not weeks.
2
Real data where possible. A prototype against synthetic data tells you the prototype works. A prototype against real data tells you the idea works. We use representative slices of real data wherever security and consent allow.
3
Same-day iteration. The user clicks through, hits a friction point, says it out loud, and we adjust that day. Sprint ceremonies and two-week demo waits would erase the whole advantage.
Output
Working demo
Clickable prototype on a real URL, against real data
Duration
3 days–2 weeks
Arch Convert: 1 night to first prototype
From you
Feedback
Hands-on testing from real users, not a review committee
Phase 3 — Production
Same codebase, hardened. Auth, persistence, monitoring, performance, security. The thing that validated the idea is the thing that ships.
1
No throwaway prototypes. The codebase that proved the idea is the codebase that ships, written for performance, security and maintainability from session one.
2
Production from the start, hardening at the end. Authentication, persistence, monitoring, error handling and integrations get layered on once the workflow is validated. We add the missing layers rather than re-architecting.
3
You own the codebase. Source, deploy config and handover docs, all yours. Run it yourself, hand it to your team, or keep us on a light retainer for the first 30 to 60 days.
Output
Production system
Source code, deploy config, handover docs — yours
Duration
2–6 weeks
Varies with scope, integrations, and compliance
From you
Decisions
Auth model, data residency, integrations to wire in
What this method is not
Naming what we avoid is as important as naming what we do.
- Not waterfall with a fresh coat of paint. A discovery phase producing a 40-page spec, a build phase executing it, and a handover phase fixing both is the thing we are avoiding.
- Not throwaway prototyping. "Build a quick prototype, then rebuild it properly" is a tax we refuse to charge, and it is no longer necessary.
- Not a deck-first engagement. If a working session produces a slide deck, we skipped the part that matters. The deliverable is software the user can click on.
- Not a fixed-scope contract negotiated against a spec doc. Software discovers its own requirements as people use it, so we scope around the success criteria from Validate rather than a feature list.
The method, in one example
Arch Convert is the cleanest case study of the method running end to end.
FAQ
That is a successful Validate phase. Finding out in 3 days that the original idea has a fundamental flaw beats finding out 6 months in after a full build. We have had sessions where the original idea shifted entirely based on what real users said when they actually clicked through something. Pivoting at validate or prototype stage costs days, not months. We are happy to walk if the work is wrong; the alternative is shipping the wrong thing.
Validate: 1 to 5 working days, depending on how scattered the user base is. Prototype: 3 days to 2 weeks for a working demo on a real URL. Production: 2 to 6 weeks, varying with scope (auth, integrations, scale, compliance). End to end, most engagements run 4 to 8 weeks from first session to a production-grade system. Arch Convert went from problem statement to working prototype in a single night, and from there to daily use at two architecture firms within 2 weeks — that is the fast end of the range, not typical.
We reuse it. The codebase that validates the idea is the codebase that ships. We write for performance, security and maintainability from session one, so there is no throwaway-prototype-then-rewrite step. The time saved on boilerplate goes into code that is already production-shaped.
The people who will actually use the tool. Not the manager who approved budget, not a project sponsor — the end users. Bring a problem statement (one paragraph, plain English), not a spec document. We will work out the spec together in the session. Optional but useful: example data, screenshots of the current workflow, and any failed attempts at solving the problem with off-the-shelf tools.
What keeps going wrong?
Tell us, and we'll come back with whether we can validate it in a week and what it would take to ship.
Bring us a problem