The Praxyt Method
We start with the work — not the technology.
Most software projects fail before a line of code is written: the system gets designed from assumptions instead of from the work. The Praxyt Method runs in the opposite order — observe the workflow, diagnose where it breaks, and only then design and build the smallest system that fixes it.
- 01
Observe
We start by watching the work, not by interviewing executives about it.
- 02
Diagnose
With the workflow observed, we map it as it actually runs and locate where it breaks: the approval that stalls in one person's inbox, the data entered three times into three systems, the exception nobody owns until a customer calls.
- 03
Design
Only now do we design the system.
- 04
Build
We build in short cycles and put working software in front of the people who will use it early — not a reveal at the end.
- 05
Refine
A system is not done when it ships; it is done when the workflow measurably improves.
The five steps, in full
Observe
We start by watching the work, not by interviewing executives about it. We sit with the people who actually perform the workflow — the inside sales rep assembling a quote, the coordinator chasing a backorder — and follow real transactions from start to finish. We note every handoff, every re-keyed field, every side spreadsheet and sticky-note workaround, because the workarounds are usually where the process truthfully lives. What you see: a short series of working sessions with your team, typically a few hours each, spread across one to two weeks. No preparation decks required from you; we learn by watching.
Diagnose
With the workflow observed, we map it as it actually runs and locate where it breaks: the approval that stalls in one person's inbox, the data entered three times into three systems, the exception nobody owns until a customer calls. Each friction point gets a hypothesis about what it costs — in hours, in errors, in delayed revenue — phrased as an estimate to validate with you, not a made-up figure. What you see: a current-state workflow map and a friction analysis you can react to. Most clients tell us this document alone is worth the exercise, because it is the first time the whole process has been drawn in one place.
Design
Only now do we design the system. The design covers the workflow itself — states, owners, escalation rules — before any screens, because a good interface on a broken process is still a broken process. We decide deliberately what the new system should not do, what stays in your ERP, and what integrations are genuinely required versus merely nice to have. What you see: a recommended system design with concrete screens and workflow diagrams, an integration list, and an implementation scope with a fixed proposal where the work is well enough understood to price it that way.
Build
We build in short cycles and put working software in front of the people who will use it early — not a reveal at the end. The employee who enters orders at 7 a.m. sees the order screen while it is still cheap to change, and their corrections shape the build. We integrate against your real systems and real data as soon as possible, because that is where the honest problems surface. What you see: regular working demos, a running list of decisions and changes, and access to the system as it takes shape. Communication is a standing weekly check-in plus a shared channel for questions — you will never wonder what happened this week.
Refine
A system is not done when it ships; it is done when the workflow measurably improves. After launch we watch how the team actually uses it, compare the result against the friction we diagnosed in step two, and tune the places where reality disagrees with the design. Handoff is explicit: documentation, ownership of the system transferred to you, and a defined support arrangement so you are never locked into us to keep the lights on. What you see: a post-implementation review against the original baseline, and a system your team owns outright.
The engagement
What working together actually looks like
Typical phases. Most engagements start with a Workflow Opportunity Review — a focused study of one workflow that ends in a map, a diagnosis, and a recommended design. If the case for building holds, the build follows as a separate, separately priced phase. You decide at each gate; there is no momentum trap.
Communication. A standing weekly check-in, a shared channel for questions as they come up, and working demos instead of status decks. Decisions and changes are logged where you can see them. If something slips or a design assumption proves wrong, you hear it from us early, in plain language.
Handoff. When the system is live and refined, ownership transfers to you: the code, the documentation, and the knowledge to run it. Support continues under a defined arrangement, but the system is yours — deliberately, so you are never dependent on us to keep it running.
Fit
Who this is for — and who it isn't
A good fit
- An operational company — distribution, manufacturing, rental, food production, lab work — roughly 20 to 250 employees.
- A specific workflow that runs on spreadsheets, inboxes, and workarounds, and visibly costs time, margin, or customers.
- Leadership that will let us watch the real work and put real users in front of early versions.
- An ERP or core system that mostly works and should stay where it is.
Probably not a fit
- You want a customer-facing product, a mobile app, or a marketing website — we build internal operational systems.
- You are looking for the cheapest possible automation of a process that is not actually costing you much.
- The goal is to replace a working ERP wholesale rather than fix a specific workflow around it.
- Nobody on your side can spare a few hours a week to show us the work and react to what we build.
Common questions
- It depends on the workflow, but the pattern is consistent: discovery and design are measured in weeks, and a focused first system is typically measured in weeks to a few months rather than quarters. We scope for the smallest system that creates meaningful leverage, which keeps timelines honest. Our article on how long an internal tool takes to build walks through the factors in more detail.
- No — and we will usually argue against replacing systems that work. Praxyt builds the operational layer between your ERP, spreadsheets, inboxes, and people. If your ERP handles accounting and inventory records well, it keeps doing that; the new system handles the approvals, exceptions, and visibility the ERP was never designed for.
- A small group: the people who perform the workflow daily, the manager who owns its outcome, and whoever can answer questions about your existing systems. We design the engagement so this costs your team hours per week, not days — their job is to show us the work and react to what we build, not to write specifications.
- Then that is the answer, and you keep the workflow map and friction analysis. Sometimes the right fix is a process change, a better use of software you already own, or doing nothing because the cost is smaller than it felt. We would rather tell you that than sell you a system you do not need — it is the only way this kind of work stays worth doing.
- We do not publish a standard price because scope varies with the workflow. Where the work is well understood after the design step, we propose a fixed build price so you know the cost before committing. Our article on what custom internal software costs explains the ranges and what drives them.
- You own it. The system, its documentation, and its data belong to you, and handoff is a built-in step of the method — not an exit negotiation. We design systems so a competent developer can maintain them without us, and we say so in writing.
Related reading
- How much does custom internal software cost?The honest ranges and the factors that move a build up or down.
- How long does an internal tool take to build?What actually drives timelines, from discovery to handoff.
- Find a workflow worth automating firstHow to pick the first workflow instead of the loudest one.
The method starts with one workflow.
A Workflow Opportunity Review applies Observe, Diagnose, and Design to the process that frustrates your team most — before you commit to building anything.