How firm are those ranges?

Firm enough to plan around, not firm enough to sign. Two projects with the same feature list can sit at opposite ends of a tier depending on integrations, data quality, and how many roles the system serves. The ranges tell you whether we’re in the same ballpark; the Workflow Review turns that into one fixed number attached to a defined scope.

How does Praxyt price a project?

Fixed proposal, after a Workflow Review. The review maps the workflow, identifies what the system must do, and produces a scoped build proposal with a fixed price before you commit to anything. You know the cost and the deliverable before the build starts, not after the invoices arrive.

What does the Workflow Review cost?

Nothing. It’s free. Its purpose is to find out whether a build is justified at all—including the cases where it’s not—before either side commits to a project. You keep the workflow map and the friction analysis either way.

Can we phase the work to spread the cost?

Yes, and we recommend it. Build the one workflow that costs you the most, let it prove itself in daily use, then decide what the second phase is worth with evidence instead of projections. Phasing also keeps each build small, which is the single biggest cost control there is.

What about ongoing costs after the build?

Support runs $150 to $600 a month depending on the size of the build — hosting, keeping it working, and a few small changes a month included. The first three months come with the build, so nothing starts until you have seen whether the thing was worth having. Full breakdown above.

Is custom software ever cheaper than the SaaS alternative?

Sometimes, over a multi-year horizon. Per-seat pricing across a growing team, plus implementation consulting, plus the hours your people spend on workarounds, can exceed a fixed build cost in a few years. Sometimes the SaaS product is genuinely cheaper. The honest comparison is five-year total cost on both sides, including labor.

Investigating cost

How much does custom internal software cost?

Most of what Praxyt builds lands between $1,000 and $25,000. Below are the three sizes we quote, so you can tell within a minute whether this is worth a conversation—rather than reading a page of hedging.

The final number comes from a Workflow Review, which maps the workflow and produces a fixed build proposal. You see a real price attached to a real scope before you commit—never an hourly arrangement where the total is discovered afterward.

Small
$1,000 – $5,000
One job, done properly. A single form, screen, or automation that removes a recurring manual step.
Typically
- A structured intake form replacing an email thread
- An automation that ends a daily copy-paste routine
- A single dashboard the team checks every morning
Medium
$5,000 – $10,000
A real workflow, start to finish. Multiple steps, owners, and states—usually connected to something you already run.
Typically
- An approval workflow with routing and a record of decisions
- An exception queue where nothing falls through
- An integration so information is entered once, not three times
Large
$10,000 – $25,000
A system several roles depend on daily, spanning more than one workflow with the integrations to match.
Typically
- A customer or vendor portal replacing status phone calls
- A scheduling or production system the floor runs on
- Several connected workflows under one set of permissions

These are real ranges, not anchors designed to make a bigger number look reasonable. If your project is smaller than the first tier, say so—we would rather scope it down than turn it away. Hosting and ongoing support are quoted separately and stated in the proposal, never discovered in year two.

After it ships

What support costs, and what it is

Software that nobody maintains stops fitting the business within a year. Support is what keeps the thing working and keeps it matching how you operate — not a line item for the privilege of calling us.

The first three months come with every build. You start paying once you have seen whether it was worth having.

For a Small build
$150/month
One form, screen, or automation.
For a Medium build
$300/month
A workflow with several steps and owners.
For a Large build
$600/month
A system a few roles depend on daily.

What that covers

It stays up: We host it, monitor it, and back it up. You never think about where it lives.
It keeps working: Bugs are fixed at no charge — it's our code, it should work. When something it connects to changes, we repair it.
Small changes are included: Add a field. Send the notification to someone else too. Add a column to the report. Two or three a month, no quoting.
A response you can plan around: Same or next business day, every time.
A quarterly fifteen minutes: What has changed in your business, and whether the system still fits it.

What it doesn’t

New workflows: A second system is a second build, priced like the first.
Anything over a couple of hours: Quoted before we start, never billed as a surprise.
Emergency cover: There is no 24/7 line. We answer fast on working days and we would rather say that than sell you a promise we would break.

You can cancel with a month’s notice, and you keep the system either way — it is yours, and it is built so another developer can pick it up.

The four things that drive cost

1. Scope: how many workflows, how many edge cases

One workflow—a quote approval queue, a backorder control tower—is a defined, contained build. Three workflows that share data are a larger one. And within any workflow, the edge cases are where scope lives: standard quotes are easy; customer-specific pricing, credit holds, and margin exceptions are the work. A good scoping process surfaces these early, because an undiscovered edge case is an undiscovered cost.

2. Integrations: what the system must talk to

A standalone tool is one price; a tool that reads and writes to your ERP is another. Modern ERPs with real APIs integrate cleanly. Legacy systems, EDI feeds, and vendor portals each add integration work—and the variance is huge, because it depends on systems you chose a decade ago. This is why integration reality is assessed before any number is proposed.

3. Data quality: what the system inherits

Clean customer and item data makes everything cheaper. If the new system must import fifteen years of inconsistent records, reconcile duplicate customers, or absorb logic buried in spreadsheet formulas, data work becomes a real line item. Nobody can price this from a feature list—it has to be looked at.

4. User roles: how many kinds of people it serves

A tool for one team with one permission level is simple. A system where sales, pricing, warehouse, and management each see different things—and customers see a portal on top—carries design and testing cost per role. Roles are worth it; they are also worth counting.

What makes a project smaller

One workflow, chosen because it costs the most today.
One or two integrations, against systems with modern APIs.
Clean master data, or a deliberate decision to start fresh.
A small number of user roles with clear boundaries.
An owner on your side empowered to make decisions quickly.

What makes a project larger

Multiple workflows bundled into one build because “we might as well.”
Legacy integration, EDI, or systems with no API at all.
Historical data migration with real cleanup required.
Many roles, external users, or customer-facing portals.
An unsettled process—software hardens whatever process exists, so redesign belongs before the build, not during it.

Common mistakes when budgeting

Comparing the build to the software subscription and stopping there. The real alternative cost includes workaround labor, errors, and the deals that slow down—see the ROI calculator.
Accepting hourly billing without a scope. An open-ended arrangement transfers all the risk to you.
Shopping for the cheapest proposal. Under-scoped proposals are not cheaper; they’re later and angrier.
Padding the first build. A second phase decided with evidence beats a first phase bloated with speculation.
Forgetting ongoing costs. Hosting and maintenance are modest but real; any honest proposal states them up front.

Frequently asked questions

: Firm enough to plan around, not firm enough to sign. Two projects with the same feature list can sit at opposite ends of a tier depending on integrations, data quality, and how many roles the system serves. The ranges tell you whether we’re in the same ballpark; the Workflow Review turns that into one fixed number attached to a defined scope.
: Fixed proposal, after a Workflow Review. The review maps the workflow, identifies what the system must do, and produces a scoped build proposal with a fixed price before you commit to anything. You know the cost and the deliverable before the build starts, not after the invoices arrive.
: Nothing. It’s free. Its purpose is to find out whether a build is justified at all—including the cases where it’s not—before either side commits to a project. You keep the workflow map and the friction analysis either way.
: Yes, and we recommend it. Build the one workflow that costs you the most, let it prove itself in daily use, then decide what the second phase is worth with evidence instead of projections. Phasing also keeps each build small, which is the single biggest cost control there is.
: Support runs $150 to $600 a month depending on the size of the build — hosting, keeping it working, and a few small changes a month included. The first three months come with the build, so nothing starts until you have seen whether the thing was worth having. Full breakdown above.
: Sometimes, over a multi-year horizon. Per-seat pricing across a growing team, plus implementation consulting, plus the hours your people spend on workarounds, can exceed a fixed build cost in a few years. Sometimes the SaaS product is genuinely cheaper. The honest comparison is five-year total cost on both sides, including labor.

Keep investigating

Want a real number instead of a range?

A Workflow Review ends with a fixed build proposal attached to a defined scope—the only kind of price worth evaluating.

Book a Workflow Review Explore Common Operational Problems