# How We Work: Validate, Prototype, Production | FluxCo Technologies > The FluxCo Method: Validate, Prototype, Production. Prototype on a real URL in days, then ship the same codebase to production. Vancouver + Auckland. Source: https://fluxcotech.com/how-we-work/ --- 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 build, so nothing gets rebuilt at the end. [Bring us a problem](https://fluxcotech.com/#contact) [See services](https://fluxcotech.com/#services) ## 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. The same software carries through from the first session to the finished system. We build it to last from day one, not because we know every requirement up front, but because we never plan to rebuild it. The FluxCo side The integrations nobody has time for. The reporting that would take an engineer. The steps that only work because someone remembers them. We take that side, and what it gives back compounds. 3,000 linked records Eagleson Properties A Jira Service Management migration with about 3,000 records linked to each other. 30-40% saved Pass the Report What buyers saved on building reports in user testing across Auckland. ## 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. Waiting two weeks for the next demo 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 The same software, made sturdy: logins, saved data, monitoring, speed and security. The thing that proved the idea is the thing that ships. 1 **No throwaway prototypes.** The software that proved the idea is the software that ships, built for speed, security and upkeep from the first session. 2 **Built to last from the start, finished at the end.** Logins, saved data, monitoring, error handling and connections to your other tools get added once the workflow is proven. We add what is missing rather than starting over. 3 **You own what we build.** The code or platform setup and the notes on how it runs live in your own accounts, and we keep running and extending it with you on the [monthly retainer](https://fluxcotech.com/pricing/). Output Production system Code, setup and run notes: yours Pace Keeps moving Feedback keeps shaping it after it ships From you Decisions Who can log in, where your data lives, which tools to connect ## 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. Validate Prototype Production ### 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.** The same software, made sturdy. Validate Prototype Production ### Eagleson 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. ## FAQ **How is this different from a typical agency engagement?** 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 of the same build, not three separate engagements. **What happens if validation kills the idea?** 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. **How fast do you move?** 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. **Do you reuse the prototype code in production, or rebuild it?** We reuse it. The software that proves the idea is the software that ships. We build for speed, security and upkeep from the first session, so there is no build-it-twice step. The time saved goes into making the real thing better. **What do I need to bring to a Validate session?** 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](https://fluxcotech.com/#contact)