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. 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
Pace
Set by user access
Moves as fast as we can get the people who do the work in the room
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
Pace
Same-day changes
Arch Convert: a working prototype the same night
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 what we build. Source code or platform configuration, 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
Pace
Keeps moving
Feedback keeps shaping it after it ships
From you
Decisions
Auth model, data residency, integrations to wire in
What this method is not
- 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 two examples
Arch Convert is the method on a tool built from scratch. Eagleson Properties is the same method on a live operation moving to a new platform.
Arch Convert: a working prototype the same night, shaped by two firms
Validate. One session with practising architects in Vancouver surfaced the real problem: existing imperial/metric converters all missed the details architects actually need, like drawing scales, fractional inches and site area units. Problem statement: one paragraph. Success criteria: a tool architects pull up daily.
Prototype. Working demo on a real URL the same night. Architects clicked through it the next day. Then iteration with real users at both firms, changing it as their feedback came in.
Production. Same codebase, hardened.
232 people have used it this year, 72 in the last 90 days. Visit convert.fluxcotech.comEagleson Properties: the migration prototyped on their own records
Validate. Before anything moved, we worked through the schema, the migration plan and the trade-offs with the client's team. Their records lived in a long-standing Monday.com setup, with the links between properties, units, owners and tenancies typed into cells.
Prototype. More than 1,500 of their real records, across nine record types, moved into a working Jira Service Management instance with the links wired up. The team opened their own records, flagged what was wrong, and we changed it the same day.
Production. About 3,000 linked records now. Every incoming email lands in one place, maintenance runs there live, and an automation filters out email that is not a request. Replies to repeat leasing questions are next.
Built alongside a live operation, without pausing it. Read how we prototyped the migrationFAQ
That is a successful Validate phase. Finding out in the first sessions that the original idea has a fundamental flaw beats finding out 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.
As fast as the feedback comes in. We put a working version in front of the people who will use it early, change it the same day they raise something, and keep going. How long the whole thing takes depends on your scope and how quickly your team can test, so we work that out together once we understand the problem. Arch Convert is the fast end: a working prototype the same night we sat down with the architects.
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 how we would validate it and what it would take to ship.
Bring us a problem