Home ／ Resources ／ How budgets and quotes work
Pricing How budgets and quotes work Every line on the quote
says how it will be accepted.
The budget for a custom system depends on what you build, what it connects to, who uses it, and who owns it after launch. A JoinX quote breaks the system into areas, modules and individual features. Every line states its specification, how it will be accepted and an estimated number of days, and the quote also lists what is out of scope. Days are the basis of the estimate; what you accept is the outcome written in the specification.
Not one lump sum, but a list you can check line by line.
The example below is based on a quote for an accessibility section on an asset manager's website (rewritten, amounts omitted). Hover over (or tap) a note to see which part of the quote it refers to.
Project contact・Sales contact・Quote date
| Area | Module | Item and specification | Estimated days |
|---|---|---|---|
| 1 Front end | Data search | Search form and results table
| 3 |
| 2 Front end | Document download | Document categories and downloads
| 3 |
| 3 Common | Project management |
| 4 |
| Common | Functional testing |
| 3 |
- 1Every item has a specification
Instead of just writing “search”, the quote spells out how the feature behaves when things work, when input is wrong, when nothing is found and when it fails. These are the points you check one by one at acceptance.
- 2Grouped by area and module
Front end, back end, app and API are listed separately and then split into modules. You can see at a glance where the effort goes, and decide what to build first and what to defer.
- 3The invisible work is listed too
Requirement interviews, flows and wireframes, progress reports, testing and retesting each get their own line. When quotes differ widely, the gap is usually whether this work was counted at all.
- 4What we will not do is written down
Anything out of scope is stated on the quote. If you want to add it later, it is quoted separately, so no one finds out at acceptance that expectations differed.
- 5Acceptance and warranty have rules
How delivery is accepted, how quickly defects are fixed and what the warranty covers are all agreed before you sign.
- 6What you receive
Source code, specification documents and design files are all handed over, and the copyright is yours. Who provides which environment is also stated up front.
Budgets differ mainly because of these 6 things.
How many existing systems it connects to
ERP, POS, payments, logistics, membership systems… every additional integration adds an interface specification, testing and exception handling.
How many kinds of users and permissions
Members, front-line staff, managers and head-office admins: the more roles there are, the more screens, flows and permission settings.
Whether legacy data must be migrated
Moving data from Excel or an old system means cleaning it, mapping fields, converting formats and then verifying that what arrived is correct.
Which platforms to cover
A website only, or iOS and Android apps plus an admin back end as well. Each platform has its own design, development and store-release work.
What level of support after launch
Support hours from 5×8 to 7×12, hosting and system administration, monitoring and backups: the operations scope sets the monthly effort after go-live.
Security and regulatory requirements
Requirements from finance, healthcare, the public sector or accessibility certification add checks, documentation and audit support.
When requirements are still unclear, don't rush to a total.
The vaguer the requirements, the less reliable a total becomes: it is either too high, or it keeps growing later. So we usually quote in phases, and at the end of each one you decide whether to continue.
Clarify requirements
We visit your site, map the flow together and build a working prototype. Scope, priorities and exceptions are settled in this phase.
Build and launch
We build item by item against the specification confirmed in Phase 1, with regular demos. After delivery, each item is accepted against its specification, and then the system goes live.
Operations and ongoing development
Hosting, maintenance, security and support run under an operations agreement. New requests are quoted separately, and the same team carries on.
Three pricing models for different situations.
| Model | When it fits | How the budget moves |
|---|---|---|
| Fixed scope | Requirements are clear and stable, for example a system that already has flows and a prototype | The total is clear; requests outside the scope are quoted separately |
| Phased iteration | Requirements need to be validated as you build, for example a new product or a process being digitized for the first time | Each phase is quoted on its own, and results decide the next step |
| PoC / MVP | Validate technical feasibility or market response first, for example an AI application or a new service | The scope is deliberately narrowed so a smaller budget gets you an answer; core security and quality requirements stay the same |
Get a rough sense of the timeline first.
These are reference timelines for common situations. The exact schedule is written into the proposal.
Before you sign, get these questions answered.
“Why do quotes from different vendors vary so much?”
Usually it is not that the same work costs different amounts, but that the scope is different. Put the quotes side by side and compare them line by line. Do they list requirement interviews, design, testing and retesting? How detailed are the specifications? What is stated as out of scope? Will the work be subcontracted? Who is responsible after launch? If you only compare totals, the cheapest quote is often the one that says the least.
“What do the days on the quote mean?”
Days are how we estimate the effort of each item, so you can see which items are heavier. At acceptance we look at whether the specification has been met, not at how many days were actually spent.
“What if I want to add a feature halfway through?”
You can. We first assess how the change affects the schedule and cost, and schedule it into development once you confirm. Requests outside the scope are quoted separately, so the bill is not totaled only at acceptance. That is also why a quote has to state what is out of scope.
“Does starting with an MVP mean lower quality?”
No. An MVP narrows the scope of the question you want to answer, not the quality standard. The core flow still has to meet the requirements for security, testing and maintainability, so the system can keep growing afterwards.
Want to know roughly what your system will take?
You don't need a specification document first. Just bring the problem you want to solve. We will help you judge the scope and point out what is most likely to push a budget off course.