It is not the deck

Every finalist has a competent deck. Market size, product, traction, team, ask. Judges have seen hundreds. The deck gets you into the room and then stops mattering.

What happens in the room is a conversation, and the conversation probes three things.

One: do you understand the customer's problem better than they do?

Not the market. The customer. A specific person with a specific job who currently does something painful. Judges listen for whether you can describe that person's day, where it breaks, and what they do today instead of using you. If your answer is a segment and a statistic, you have described a market. If your answer is a workflow and an exception, you have described a customer.

For QuantumByte, that meant talking about the people who actually built tools on the platform: students, village operators, the supervisor who had been running a process in a spreadsheet. Not "SMEs in Southeast Asia."

Two: what is your evidence, and how was it established?

Every founder has traction numbers. The question is what stands behind them. Judges ask, politely, where a number came from, and they notice whether you answer with a source or with a bigger number. A modest figure with a clear origin beats an impressive figure with a vague one, every time.

This is the same discipline I wrote about in the numbers I will and won't put on a slide. It applies to pitches exactly as it applies to case studies.

Three: what is the smallest credible next step?

The weakest answer to "what would you do with this" is "scale." The strongest is a specific, bounded next step with a named outcome: this customer, this capability, this evidence of success, by this date. It shows you know what you do not know yet and have a plan to find out cheaply.

Investors and judges are pattern-matching for founders who ship in slices, even if they never use that word. A giant plan is a risk. A sharp next step is a bet they can size.

Why this is the same test a client runs

If you strip the competition context away, the three questions are what every serious buyer asks a builder. Do you understand my people's work? Can you show me evidence, honestly sourced? What is the first small thing we do together, and how will we know it worked?

I did not prepare for the competition by rehearsing the deck. I prepared by rehearsing those three answers until they were boring. That is the preparation I would recommend to any founder walking into a pitch, a sales call, or a board meeting.

One more thing

Winning a national round is a milestone, not an outcome. It does not change a single customer's Monday morning. The work that earned it, and the work that follows it, is where the value is.

What we did the week after

We went back to the customers whose stories carried the pitch and asked what they needed next. Not a bigger platform. In every case it was a smaller thing: an export in the format their office already used, an exception the tool did not yet handle, a way to hand the app to a colleague. That list became the next month of work. Winning gave us attention. The customers gave us the plan.

Judges, like clients, test whether you know the customer, can source your evidence, and can name the next small step.

Three kinds of outcome

Measured. A baseline was recorded before the change, the same thing was measured after, and both are in a document I can show you. This is rare, and it is the only kind I state without qualification.

Reported. The client or the project team stated the result. I believe it, it came from people who were there, but I did not measure it and cannot reproduce it. This is most of what appears in any consultancy's case studies, including ours from the Quantum years.

Projected. Somebody calculated what should happen if the system is used as designed. Useful for planning. Not an outcome.

The sin is not having reported or projected numbers. The sin is presenting them as measured.

How to read a case study

When you read any builder's case study, including the ones on this site, ask four questions of every figure:

1. Who measured it, and when?
2. What was the baseline, and was it recorded before the work started?
3. Is the arithmetic internally consistent? A "50 days to 3 days" claim is a 94 percent reduction, not "around 80 percent." If the percentage and the days disagree, one of them is a slogan.
4. Does the number describe a product feature or an organizational result? "Five times faster batch processing" is about the software. "Restructuring finished a quarter earlier" is about the organization. Both can be true; they are different claims.

What I do on this site

Every project story here has a "what changed" list, and under it a provenance line saying where those outcomes come from: the project's own case-study record, a public source, or a measurement. When a figure in the original record was inconsistent, I dropped the inconsistent part and kept the part I can stand behind. Where I only have the scope of what was built and no outcome evidence, I say what was built and stop.

The Telkomsel competency-mapping story is a good example. The project record describes the mapping time falling from around fifty working days to three. I am comfortable stating the days, because they describe an observed change in a specific process. I am not comfortable turning that into a marketing percentage that does not match the arithmetic. So you will see the days, not the percentage.

Why bother

Because the buyer I want to work with is going to check. Founders and operating leaders who have been burned by vendor decks read case studies with a pencil. If they find one inflated number, they discount everything else, including the parts that are true. Labeling provenance costs me a few impressive-sounding percentages and buys me a conversation with someone who now trusts the rest of the page.

For anyone writing their own case studies

Keep a column in your project record for how each outcome was established. Write the provenance on the slide, in small type if you must. And when a number and its percentage disagree, fix it before someone else finds it.

It also means some of the strongest-sounding figures from the original deck do not appear here at all, because the record did not say how they were established. Their absence is the point.

State measured numbers plainly, label reported ones, and never let a slogan outrank the arithmetic.

We ship in slices, and every slice has to be observable.

What a slice is

A slice is the smallest piece of software that produces one outcome for one beneficiary, end to end. Not a component, not a screen, not "the backend for phase two." One person, one thing they can now do, from trigger to done.

For a telecom-expense tool, a slice might be: a finance analyst uploads one carrier contract and sees its plan details extracted into a searchable record with a source reference. Nothing else. No dashboard, no chatbot, no recommendations yet. But the analyst can do something on Friday that they could not do on Monday, and they can see it.

The loop

Every slice runs through the same five steps. I have written them up in more detail on the process page, but the shape is simple.

1. Promise. Before any code, a short card: the outcome, the scope, what evidence will show it works, who will verify it, by when, what it depends on, and what would make us stop.
2. Back-brief. The engineer explains, in their own words, the user's problem, the approach, what will be tested, and what will not change. If the explanation does not match the promise, we have caught the misunderstanding before it cost a week.
3. Build. Small enough to inspect and reverse. Linked to the promise. AI-generated code treated as untrusted until reviewed, like any other contribution.
4. Verify. The primary workflow, the likely failure, the permission case, and the "what if the integration is down" case. Recorded with the exact environment and data used, and with what was not checked.
5. Demo. To the person who will use it, in a real scenario, including a failure. Then a disposition: accept, accept with conditions, or go again.

Why observable matters more than small

Small is easy to fake. A team can ship tiny pieces of nothing for months. Observable is the discipline: at the end of the slice, a specific person can watch a specific outcome happen. If they cannot, the slice is not done, however much code was written.

This is also what makes the demos possible. When every slice has already been shown to a user in a real scenario, demonstrating in front of a conference audience is just doing it again in a bigger room.

What it changes for the client

You see progress every week or two, on your data, with your people. You can stop, redirect, or expand at any slice boundary without losing work. And you never arrive at a launch day, because there is no launch day. There is a slice, then another, and at some point the team notices the work has moved into the tool.

If you are commissioning software

Ask the builder what the first slice is, who benefits, and how you will observe it. If the answer is "the data model and authentication," ask again. Those are ingredients. You are buying outcomes, one at a time.

When a slice is not ready

A slice does not start until it has a beneficiary, a confirmed requirement, a starting state, its acceptance and failure scenarios, a named verifier with a date, and the access and data it needs. If any of those is missing in a way that would change the design, the slice waits and the gap becomes this week's work. That rule is what stops the loop from becoming a treadmill of half-started pieces.

One beneficiary, one outcome, observed by a real person: that is the unit of shipping.

That sounds limiting. It is the opposite. Constraints are what turn a demo into a system people trust with real decisions.

The problem constraints solve

Take the competency-mapping work for Telkomsel. Thousands of job positions had to be mapped to an approved competency catalog. A person doing this reads a role, interprets the organizational context, and picks entries from the catalog. It is slow, it is inconsistent between people, and every time the catalog changes, the work starts again.

An unconstrained language model would produce beautiful, fluent competency descriptions. It would also invent competencies that do not exist in the catalog, and HR would spend the next quarter cleaning up. The output would be plausible and unusable.

The pattern

Four rules make the difference.

Catalog-only outputs. The model can only choose from the approved list. It reads the role, extracts the job functions, and matches them to existing entries. It cannot write a new one. This single rule removes most of the risk of AI in enterprise settings: the vocabulary is the organization's, not the model's.

Confidence and reasoning beside every match. Each result carries a confidence score and a short explanation of why. A reviewer can sort by confidence, read the reasoning for the borderline cases, and ignore the rest. Without this, a reviewer has to check everything, and the time saving disappears.

Human review, by design. The tool does not "decide." It proposes, and a named person confirms. The review step is part of the workflow, with its own screen, not an afterthought bolted on when someone gets nervous.

Batch visibility. Thousands of roles are processed in runs. A dashboard shows which run is in progress, what has finished, and where it stopped. Results export to Excel, because that is the format the downstream planning actually uses.

Rules on top of the model

One more piece is easy to miss: predefined rules adjust the matching. The organization's own policies, which roles map to which families, which functions outrank others, are encoded as weights the model has to respect. The model provides the reading comprehension. The rules provide the institution's judgment.

How to tell if an AI vendor understands this

Ask three questions. Can the system produce an answer that is not in my approved vocabulary? Can a reviewer see why each answer was chosen? What does the screen look like when the model is unsure? If the answers are "yes," "no," and "it just picks something," you are buying a demo.

For founders

If you are building AI for organizations, spend your effort on the boundaries: the allowed outputs, the review interface, the run visibility, and the export. The model is the least differentiated part of your product. The lines you draw around it are what a buyer is paying for.

When the catalog changes

The hardest moment for any mapping system is not the first run. It is the day the catalog is revised. Entries are renamed, merged, or retired, and every previous mapping is suddenly in doubt. This is the property to design for from the start: when outputs are catalog-only and every match carries its reasoning, a re-run can be mechanical. The roles whose matched entries changed can be found, re-matched against the new catalog, and routed back through review with the earlier reasoning beside the new proposal. Without those constraints, a catalog change means starting the whole project again.

Constrain the vocabulary, show the reasoning, keep a person in the loop, and make every run visible.

I want to be careful about what this does and does not prove.

What it does not prove

It does not prove that anyone can replace a software team. The enterprise systems Quantum builds, for command centers, logistics networks, and certification bodies, need engineers, security review, integration, and the discipline of a delivery process. Two days does not produce that, and nobody in the workshops thought it would.

What it does prove

It proves something more useful: the person closest to a workflow can build the first version of the tool for that workflow, if the platform meets them where they are.

The village applications are the clearest example. A rice-stock tool for Duda Timur, a child-health monitoring tool for Kauman, a harvest-recording tool for the women's farming group in Cibiru Wetan. None of these would ever have reached the top of a software company's roadmap. They were built by the people who needed them, because those people understood the trigger, the steps, the exceptions, and what "done" looks like better than any outside analyst could.

That is the same discovery material I spend weeks extracting from enterprise clients. The builders already had it in their heads.

What the platform has to do

The lesson for anyone building tools, low-code or otherwise, is about where the effort goes:

1. Make the first hour rewarding. Both groups had a working screen with their own data in it before lunch on day one. Without that, you lose the room.
2. Speak the workflow, not the schema. Nobody in Banyuwangi wanted to define an entity. They wanted to record a harvest. The platform has to start from the action and derive the data.
3. Make exceptions cheap. Real workflows have a "what if the stock arrives damaged" case. If handling it takes an engineer, the tool stays a toy.
4. Keep the result shareable. An app that only runs on the builder's laptop is a demo. The moment the school could hand a link to other teachers, the app became real.

Why a founder should care

If you run an operation, the fastest path to a useful internal tool is often not a vendor and not your IT backlog. It is the supervisor who has been keeping the process alive in a spreadsheet, given a platform that respects their knowledge and a couple of days of guidance.

That does not remove the need for professional engineering when the tool has to scale, integrate, or carry sensitive data. It does change where you start. Start with the person who knows the work.

What the two days looked like

The format was the same for both groups. Day one started with each participant naming one thing they record, track, or report in real life, and building a screen for exactly that before lunch. The afternoon was spent adding the second step of their workflow and the first exception. Day two was about making it real: entering actual data, letting someone else use it, and fixing what confused them. Nobody was taught what a database is. Several people built one anyway, because their workflow needed it, and that is the correct order to learn it in.

The person closest to the problem can build the first version, if the tool speaks their workflow instead of your schema.

Nothing was faked. The problem is that four different events were treated as one.

Four events, four questions

Acceptance is a contractual event. A named person confirms that the agreed scope works against the agreed scenarios. The question it answers: did we build what we said we would build?

Adoption is a behavioral event. The people the tool was made for use it for the real work, in place of whatever they did before. The question: is the work now happening inside the tool?

Value is an operational event. Something the organization cares about has measurably changed against a baseline: less time, fewer errors, faster escalation, a risk that no longer occurs. The question: is the operation better, and can we show it?

Renewal is a relationship event. The client chooses to continue, extend, or start something new. The question: do they want more of this?

None of these proves another. Acceptance does not create adoption. Adoption does not guarantee value. Value does not guarantee renewal, and renewal sometimes happens without value, which is its own problem.

What to measure for each

Each event needs its own evidence, and it should be planned during discovery, not discovered at the end.

• For acceptance: the scenario list, including the failure and permission cases, and the name of the person who verifies them. Written before the build starts.
• For adoption: the share of the real workload that passes through the tool, week by week, and the number of people who touch it. A tool used by one champion is a pilot, not a product.
• For value: the baseline you measured in discovery, and the same measurement after adoption. If there was no baseline, say so honestly and start one now.
• For renewal: a conversation with the sponsor about what they would do next, held before the current work ends, not after.

Why this matters more for workflow software

Consumer apps get adopted or deleted; the signal is fast. Enterprise workflow software can be accepted, installed, and ignored for a year, because the people who bought it are not the people who would have to use it. The certification lifecycle work for BSMR only counts if training providers, verification admins, and finance admins are actually moving submissions through it. The transport platform for Avian only counts if dispatchers and drivers run their day inside it.

So the design of the project has to include the adoption plan: who is trained, who is coached in the first weeks, what the fallback is when the tool is unavailable, and who on the client side owns the change. That is not a consultant's add-on. It is the second half of the build.

For sponsors

When a builder tells you the project is done, ask which of the four events they mean. Then ask for the evidence for the other three. If you get an honest "not yet" with a plan, you have a partner. If you get a puzzled look, you have a vendor.

The champion problem

There is a specific failure worth naming. One enthusiastic person on the client side uses the tool constantly, reports back that it is wonderful, and unintentionally hides the fact that nobody else has logged in. Adoption metrics have to count people and workload, not sessions. If ninety percent of the activity comes from one account, the project is a pilot with a fan, and the honest next step is to find out why the other nine people are still on the old path.

Sign acceptance, then watch adoption, measure value, and only then talk about renewal.

What a decision actually needs

Picture the person who has to decide. A division head with fifteen minutes between meetings, three dashboards open, and a report from last month that nobody trusts. They do not need more charts. They need four things:

1. What is happening, in one sentence, with the number that matters.
2. Why the system thinks so, in plain language, with the signals it used.
3. What it recommends, as a specific action with an owner.
4. What would change its mind, so they know when to revisit.

A recommendation without the second item is an order from a machine. Leaders do not take orders from machines, and they should not. A recommendation with its reasoning beside it is a colleague's memo. That, they can act on, argue with, or overrule with a reason.

Early warning beats late analysis

The most valuable output of a decision-support system is not the quarterly analysis. It is the signal that arrives two weeks before the problem, when a small action still fixes it. That means the system has to watch continuously, compare against a baseline, and speak up only when the pattern is real.

The design question is not "can we detect it." It is "how do we present it so the person believes it early enough to act." The answer, again, is reasoning next to the alert, and a short history of how often that kind of alert turned out to be right.

Explainable by construction

There is a lot of talk about explainable AI as a technical property. In practice, explainability is a product decision made at the start. If the system stores the signals it used, the rule or model that fired, and the confidence it assigned, then explaining is a matter of showing. If it does not store them, no amount of later work will make it trustworthy.

This is the pattern behind the Qompass decision-support work: a unified view of internal and external information, early-warning analysis, and recommendations that carry their reasoning with them into executive and departmental dashboards. The technical components matter. The reason leaders use it is that every suggestion can be interrogated.

A test you can run tomorrow

Take the last automated recommendation your organization received. Ask whoever received it three questions: did you act on it, why or why not, and could you tell where it came from. If the answer to the third question is no, the first two do not matter. Fix the third.

For founders building in this space

Do not sell prediction. Sell the brief. Show the decision-maker a screen with the situation, the reasoning, the action, and the owner, and let them tell you what is missing. What is missing is your roadmap, and it will not be a better model.

Where the baseline comes from

None of this works without a baseline, and most organizations do not have one. The first job of a decision-support system is often not to recommend anything. It is to watch quietly for a few weeks, establish what normal looks like for each signal, and show that history to the people who will later receive alerts. When the first early warning arrives, they can see it against the pattern. An alert without a visible baseline is just a red badge, and people learn to ignore red badges within a month.

Data becomes a decision when the reasoning travels with the recommendation and reaches the person who can act.

Scope is not a list of features

At national scale, the feature list is the least interesting document on the table. Everybody agrees that citizens should be able to do the thing. The hard questions are about authority:

• Who decides what "the thing" is when two agencies describe it differently?
• Who accepts that it works, and against which scenario?
• Who can say stop?

If those three questions have no names attached, the feature list is fiction. Work will proceed, demos will happen, and nothing will be released, because nobody is allowed to say yes.

I had learned a version of this on smaller projects. Seeing it at this scale made it a rule: before any build starts, name the decision owner, the acceptance authority, and the person who can halt the work. Three names, written down, agreed by both sides.

The smallest end-to-end outcome

The second lesson is about size. When the ambition is national, the temptation is to plan for the whole thing at once, because anything smaller looks unambitious in a room full of ministries.

The opposite is true. The credible plan is the smallest outcome that runs end to end for one real user: one service, one citizen, one complete journey, on real infrastructure, accepted by a named person. Everything that follows is a repetition of a pattern that already works. Everything planned before that first slice exists is a hope.

This is not a small-company bias. It is how any system that has to survive contact with the public gets built. You find the narrowest path that proves the whole chain, you walk it, and then you widen it.

What I carry back to client work

Three practices came home with me from that room, and they now apply to every engagement, including the ones for companies of fifty people.

1. Decision rights before design. A workshop that ends without named owners for decisions and acceptance has not ended. Schedule the next one.
2. One slice that touches everything. The first deliverable should cross every boundary the final system will cross: the user, the data, the permission, the integration, the report. Thin, but complete.
3. Separate what was decided from what was discussed. Meeting notes are not decisions. A decision has an owner, a date, a reason, and the document it changed.

If you are sponsoring a large program

Ask, in the first planning meeting, who can accept the first release and who can stop it. If the answer is a committee, ask which member signs. If nobody can say, you have found the real first deliverable of the program, and it is not software.

The boring documents are the real ones

What I took away had nothing to do with architecture diagrams. On any platform with many stakeholders, the documents that decide the outcome are the list of who can decide what, the scenario a first release will be judged against, and a dated record of the decisions already made. Those are dull to write and easy to skip when everyone is enthusiastic. They are also the only things that survive a change of personnel, a change of minister, or a change of vendor. On a program that will outlive every individual contributor, they are the product, and the software is an implementation of them.

Name who decides, who accepts, and who can stop, then build the thinnest slice that touches everything.

I do it the other way around. The first artifact is a person's day.

Start with one person, one day

Pick the person whose day the software has to survive. For a transport system, that is the dispatcher and the driver. Not the sponsor, not the IT lead. The person with the tightest loop.

Then write their day as a sequence:

trigger → what they do → what they look at → who they hand off to → where they wait → what decision they make → what goes wrong → how they know it is done

Do this for the most common case and for the exception they mention first. The exception is never optional. It is usually the reason the last tool was abandoned.

What that sequence tells you

Each step of the day translates directly into a design decision.

• The trigger is your entry screen. If the day starts with a phone call, the first screen should accept a phone call's worth of information, not a form with twenty fields.
• What they look at is your default view. For a dispatcher, that means seeing deliveries, drivers, and progress together, with exceptions visible at a glance.
• The handoff is where a second role appears. In the Avian project, the dispatcher's plan becomes the driver's task list. Two people, two devices, one record.
• The wait is where you either show status or lose trust. Nobody minds waiting when they can see why.
• How they know it is done is your acceptance test. For a driver, done is a photo at the door. For the dispatcher, done is the day's board with nothing red on it.

Then, and only then, the data

By the time the day is mapped, the data model is mostly written for you. The entities are the nouns in the sequence. The states are the columns of the dispatcher's board. The permissions are the handoffs. You still have to design it properly, but you are designing something you have already watched being used.

Doing it in this order also protects you from the most common enterprise failure: a beautiful schema that forces people to enter data the tool needs but they do not have yet. The day tells you what is actually known at each step.

A practical test

Before I show a first slice to anyone, I run the operator's day through it, out loud, as that person. If I have to explain a step, the step is wrong. If I have to switch to another tool for a piece of information, the screen is incomplete. If the exception has no home, we are not ready.

If you are commissioning software, ask your builder to walk you through one person's day in the product before they show you an entity diagram. It is a small request, and it tells you almost everything about whether the result will be used.

Map the day, then the data. Software that fits the hours gets used; software that fits the schema gets routed around.

That is the job Journo does. I designed and built it end to end, and the code is public at github.com/rndm-jpg/journo. This post is the walkthrough I wish someone had written for me before I started.

The shape of the problem

Three things make this harder than "scrape and save":

1. Every source is its own structure. A single generic scraper produces garbage. Each source needs a crawler that knows where the content lives and a parser that knows what a place mention looks like there.
2. A name is not a place. "Sunda Kelapa" is a harbor, a mosque, a district, and several restaurants. The pipeline has to turn a string into a specific location with coordinates, or admit it cannot.
3. The work never ends. New articles arrive daily, and a good match today should not be rediscovered and re-uploaded tomorrow.

How it is built

Source registration. A source is an identifier tied to a crawler function and a parser module. Adding a publisher means adding those two pieces and registering them. Nothing else in the pipeline changes.

Crawl and parse. Crawlers collect raw content per source. Parsers pull candidate place mentions out of that source's HTML or JSON, along with whatever context sits around them.

Enrichment with spaCy. Before matching, spaCy adds location context to each candidate, so "the cafe on the corner in Kemang" carries "Kemang" into the search rather than losing it.

Matching with SerpApi and Who's On First. Each enriched candidate is searched, then cross-referenced against Who's On First gazetteer data so the coordinates and the administrative context agree.

Scoring and thresholds. A match is scored on names, descriptions, contacts, and websites. A configurable threshold drops weak matches. A unique place identifier stops the same place being processed twice across sources and runs.

Operator dashboard. A React and Next.js frontend, backed by Django APIs, shows each source's processing session, how many pages and places it has handled, and where it stopped. Nobody should have to read logs to know whether last night's run worked.

Parallelization. The amount of concurrent work is configurable, so the same pipeline runs on a laptop and on a proper server.

What I would tell a founder

The interesting engineering was not the scraping. It was deciding where a human needs to be able to look. Every stage writes its state where the dashboard can show it, because a pipeline that fails silently costs more than one that never ran.

The second lesson: keep the per-source code small and boring. The clever parts, enrichment, matching, scoring, are shared. The parts that break, the parsers, are isolated and cheap to fix.

If your product depends on turning messy public content into structured records, this is a workable pattern. Read the matching write-up in the repository if you want the detail, and the project story for the shorter version.

What I deliberately left out

There are no throughput numbers in this post, because the honest answer is "it depends on the source, the hardware, and the threshold you choose." A strict threshold gives you fewer, cleaner places. A loose one gives you volume and a review queue. That trade-off belongs to the product owner, which is why it is a configuration value and not a constant buried in the code. The same goes for parallelization: the pipeline should fit the machine you have, not demand the machine I had.

Isolate what breaks, share what is clever, and make every stage visible to a person.

They do not. They buy a workflow that works on Monday morning, with their people, on their data, in their building. Everything else is decoration.

The three checks

When a serious buyer evaluates a builder, they are quietly running three checks. If you sell software, you should know what they are. If you buy software, you should run them on purpose.

Check one: will the thing survive contact with my operation? They have seen demos. They have bought platforms that looked wonderful in the vendor's environment and collapsed the first time a field officer had no signal, or an invoice arrived in a format nobody expected. The question behind the question is: has this builder seen a real case, and did they design for the exception?

Check two: who is accountable when it does not work? Large organizations are built from handoffs. A vendor who says "the integration team will handle that" has just told the buyer where the project will stall. What they want to hear is one name that owns the outcome, and a plan for what happens when a dependency fails.

Check three: can I show my boss the result without a presentation? Every sponsor has a sponsor. If the result of the project needs a slide deck to be understood, the sponsor is exposed. If the result is a screen that a manager can open on Monday and see work moving through, the sponsor is safe. Buyers pay for safety.

What this did to how we sell

We stopped leading with capabilities. We lead with a recent case from the client's own operation, mapped from trigger to completion, with the exceptions marked. Then we propose the smallest end-to-end slice that would remove one wait or one re-entry from that map, and we name who on their side will confirm it works.

The proposal is shorter. The conversation is longer, because it is a real conversation about how their work happens. Deals take about the same time to close, but the projects that follow are calmer, because nobody is discovering the workflow after the contract.

What this did to how we build

Every slice we deliver has to pass a simple test before it is demonstrated: run the primary workflow, run the most likely failure, run the permission case, and record exactly which environment and which data it was tested on. Then show it to the person who will use it, not only the person who bought it.

That last part matters more than any feature. The people who use the tool decide whether it lives. If the dispatcher, the officer, or the analyst cannot get through their real case faster than before, the project is not done, whatever the contract says.

If you are buying

Ask the builder to describe the last exception they designed for. Ask who owns the outcome by name. Ask to see the result on a screen, not a slide. If the answers are quick and specific, you have found someone who understands what you are paying for.

What it did to hiring

The rule from day one still holds: people are paid by clients who have already paid. It has meant growing slowly and choosing engineers who are comfortable sitting with a dispatcher or an officer and asking what happened last Tuesday. That is a different skill from writing code, and it is the one I now interview for first. A brilliant engineer who cannot describe the user's day will build a brilliant system that the user routes around.

Enterprises pay for a workflow that works on Monday, owned by a name, visible without a deck.

I no longer open with "walk me through your process." I open with "show me the last time this happened."

Why the described process is fiction

When you ask a manager to describe how work flows, you get the happy path. It is honest, but it is an average of a hundred cases, and averages do not have exceptions. The exceptions are where the software will break, and where the people doing the work spend most of their day.

A recent real case has none of that smoothing. It has a specific trigger, a specific person, a specific wait, and the moment somebody made a judgment call that no document mentions. That is the material a workflow tool is actually made of.

The six questions

Once someone has a real case in front of them, I ask the same six things every time:

1. What triggered this? A call, a form, a message, a missed deadline. The trigger defines the entry point of any tool.
2. What did you do next, and why? The "why" reveals the rule they are following, which is usually not the written one.
3. What information did you need but not have? This is the list of things the system should put on the screen before anyone asks.
4. Where did you wait, or type the same thing twice? Waits and re-entry are the cost centers. They are also the easiest wins.
5. What was unusual about this case? Every case has something. That something is the exception path, and it needs a home in the design.
6. How did you know it was safely done? The answer is the real definition of complete, and it becomes the acceptance test.

Then I write each answer down with a label: observed, reported, or my interpretation. Three weeks later, when the team disagrees about how something works, that label is what stops the argument.

What it changes in the build

Discovery done this way produces a map that looks like this: trigger, action, artifact, handoff, decision, exception, end state, downstream consumer. It is not beautiful. It should not be beautiful yet. It is true, which matters more.

From that map, the first slice of software almost designs itself. It is the shortest path from the trigger to "safely done" for the most common case, with the most common exception handled and the rest visibly parked. Everything else waits until that slice is in someone's hands.

If you are about to brief a builder

Bring a recent case, not a process document. Bring the person who handled it, not only their manager. Expect the builder to ask what was unusual, and be honest about the part where you improvised. That improvisation is not a flaw in your operation. It is the requirement nobody wrote down.

A note on recording

The point of the labels is not bureaucracy. It is memory. In a police operations project, the person who told you how a dispatch actually works may be on a different shift next week, and the person replacing them may describe it differently. If the first account was recorded as "reported" with a date and a name, the difference becomes a question to resolve, not a contradiction that stalls the build. I keep the notes short, one line per answer, and I keep the labels honest even when the interpretation is mine and probably right.

Ask for the last real case, label what you heard, and design for the exception you were told about.

That sounds obvious. In practice it is the hardest discipline in a young software company, because everything about the early days pushes you the other way. You want a team. You want to look like a real firm when you walk into a meeting. You want to say yes to the interesting project that needs four people you do not have yet.

Why the rule exists

A services business runs on one number: cash collected from work that is finished and accepted. Not pipeline, not proposals, not "we are close." I have watched good teams die of optimism, hiring for the deal that was about to close. The deal slips a quarter. Payroll does not.

So the rule is simple. Headcount follows revenue. Revenue follows delivered outcomes. Delivered outcomes follow clear scope. If I cannot trace a hire back to an invoice, the hire waits.

It has a second benefit that I did not expect. When you know the money is real, you can afford to be honest with a client. You can say the workflow does not need an app yet. You can say the scope they described is three projects, not one. You are not desperate, so you can be useful.

What "revenue first" changes about the work

It forces me to price outcomes, not hours of enthusiasm. Every engagement has to answer three questions before anyone starts:

1. What result must exist at the end, and who will confirm it exists?
2. What is the smallest version of that result we can show working?
3. What does the client have to provide, and by when?

If a prospect cannot answer the first question with me, we are not ready to start, no matter how excited both sides are. That is not a sales tactic. It is the only way I know to keep a small company from drowning in half-finished work.

Saying no early

The most expensive projects are the ones you should have declined in the first meeting. This month I turned down two. One wanted a platform with no owner on their side who could accept it. The other wanted a fixed price for a scope that changed twice during the call.

Declining early is a service to the client too. They lose nothing except a vendor who would have disappointed them slowly. If you run a company and a builder tells you no in the first conversation, that is the person worth calling back with a smaller, sharper problem.

What this means if you are thinking of hiring us

You will get a small team that grows only when the work has earned it. You will get a scope that names the outcome, the evidence, and the person who accepts it. You will get straight answers about what is worth building, including "not yet."

The $20K is not a war chest. It is a runway that ends fast, and it is meant to. It keeps me focused on the only thing that matters in the first year: finish something a client is glad they paid for, then do it again.

What I have already gotten wrong

Two months is enough time to make mistakes. I underpriced the first engagement because I wanted the logo, and I am still paying for that in hours. I also let one scope conversation drift into a second and third meeting without writing anything down, and had to reconstruct what we agreed from memory. Both errors have the same fix: write the outcome, the price, and the acceptance in one page before the second meeting, and read it aloud at the start of the third.

Pay for people with money you have already collected, and you will never have to lie to a client to make payroll.