How we work
First we build it with you. Then it is yours to build on.
The sequence has two stages. In stage 01 we build the first system with you: six steps, two to five weeks, start to live. In stage 02 the framework becomes available to you, and you choose who builds what comes next. This page takes each in turn: what happens, who we need from you, and what you hold at the end.
Stage 01 · Phlo Enterprise Systems
The first build: six steps, and where the time goes.
The first build is not a pilot. It is a live system, and it is where your operation gets described. The bar is to scale. Three fifths of the build is spent before any code is written, and a quarter after it. The timeline does not shrink because anything was rushed: one band disappears, because the foundations already exist.
01 · 15% of the first build
Discovery
- What happens
- We visit your facility and watch the operation run: the gate, the stores, the floor, the accounts desk. We follow one record from start to finish and collect the slips, registers and spreadsheets it passes through. We ask about the cases that do not follow the rule.
- Who we need from you
- The people who do the work, doing it as they normally do, with time for our questions as we go. And one person senior enough to say which processes matter most.
- What you hold at the end
- A written account of what we saw, in your team's own words, with the open questions listed.
02 · 25% of the first build
Process mapping
- What happens
- What we saw becomes a documented process map: every workflow, every handoff, every role, and every exception your team works around. This is the largest band of the first build, on purpose. A system built on a wrong map is wrong everywhere.
- Who we need from you
- The supervisors and managers who know why things are done the way they are, to read the map and correct it. Short sessions, more than once.
- What you hold at the end
- The process map: your operation as it actually runs, written down in one place. Its entities, its handoffs and its exceptions are named here for the first time.
03 · 20% of the first build
Scoping and sign-off
- What happens
- The map becomes a specification: every screen, every action, every data field, every role and what it may do, defined before a line of code is written. You review it and we revise it until you agree it.
- Who we need from you
- The person who owns the outcome, to read the specification closely and sign it off. Whoever holds the business rules, to confirm them: rates, limits, who approves what.
- What you hold at the end
- The agreed specification. It is the build, not a document about it.
04 · 15% of the first build
Build
- What happens
- The system is built to the agreed specification, on the framework, with AI. This is the band a traditional build spends months on. Here it is one of the shorter ones, because the foundations exist and the specification is settled.
- Who we need from you
- Very little. Someone to answer a question when one comes up, and the reference data the system starts with: your items, vendors, customers and users.
- What you hold at the end
- A working system on a test address that your team can sign in to.
05 · 15% of the first build
Review
- What happens
- Your team tests the system against the specification, with real cases, including the awkward ones. Issues are logged and resolved before anything goes live.
- Who we need from you
- The people who will use it every day, at each role, running their own work through it. This is the step where your team's time matters most after discovery.
- What you hold at the end
- A system your own people have tested, with every logged issue resolved.
06 · 10% of the first build
Launch
- What happens
- The system goes live and your team is trained on it, role by role, on the screens they will use.
- Who we need from you
- Every user, for their training. And a named person on your side for us to work with from then on.
- What you hold at the end
- A live system and a trained team. Hosting and support start on day one.
Your team's time
Your people are needed at the start and at the end.
A traditional build is carried by your own people, on top of their jobs, for the duration. Here the demand is concentrated. Your team's knowledge is needed while we watch, map and specify. Their judgement is needed again when they test. In between, the build asks almost nothing of them.
We do not publish a number of hours, because it depends on how many processes and sites are in scope. It is part of what we come back with after the first conversation.
After go-live
Hosting and support start on day one.
Going live is not the end of the engagement. The system is hosted and supported from the day it goes live, on a server we manage or inside your own infrastructure.
Then the operation changes, as it always does. A rule is tightened, a site opens, a report is wanted that nobody thought of. Changes are agreed with you and built on the same foundation, only smaller. What gets changed, and when, is your decision.
What the first build leaves behind
Four things you hold when stage 01 ends.
Only the first is what a software project normally delivers. The other three are why the next system is quicker, whoever builds it.
- A live systemIn use by your own people, tested by them against the specification, hosted and supported.
- The model of your operationThe process map and the agreed specification: your entities, events and exceptions, written down in your floor's own words.
- The recordEvery action since go-live, stored as an event that is never overwritten. A system of events explains what that allows.
- A foundation that carries forwardUsers, roles and permissions, approval chains and reporting already exist. A second system reuses them and the recorded history.
Stage 02 · Phlo Framework
Who builds the next system is up to you.
After the first build, the framework becomes available to you. There are two routes, and choosing one does not close the other.
Route A
Your teams, on the framework
Your own engineers and product people build the next system on Phlo. They start from the model of your operation and the record the first system has kept, not from a blank page. The people who run the operation become the people improving the system, and nobody walks out with the knowledge when an engagement ends.
Route B
The same engagement again
We carry on building for you. The six steps repeat, but discovery and mapping begin from what is already written down, and the foundations are in place. The second system costs a fraction of the first.
Choosing route B for the second system does not rule out route A for the third. What this page cannot tell you is the terms on which the framework is made available, or what it costs. Those are settled in the first conversation, scoped to the engagement.
Before any of it
The first conversation is about your operation, not a demo.
There is no form to fill in. Write to us by email or WhatsApp and tell us, in a few lines, how the operation runs today and where the record gets lost.
On the first call we ask questions: what moves, who touches it, where the exceptions are, what you use now. Every system is scoped and built with you, so there is no standard product to walk through.
If you have an IT or engineering lead, bring them. The question of who builds your second system is better raised at the start than after the first one is live.
We come back with what it takes to build it: the processes, the scope and the timeline. You decide from there.
Get started
Start with a conversation about your operation.
Tell us how your operation runs today, and we will come back with what it takes to build it: the processes, the scope, and the timeline. Every system is scoped and built with you, so the first conversation is about your operation, not a demo.
coffee@jetbro.inWhatsApp +91 90999 62227