Process
How a request becomes a working system
Seven stages from the first questionnaire to a system in daily use, with payment tied to milestones and a written decision at every gate.
What usually goes wrong in a build
Work starts before the scope is agreed, the scope grows without anyone pricing it, and the finish line moves because nobody wrote down what finished means. Each of the gates below exists because of one of those.
What is fixed and what is yours to shape
The gates are fixed: review before proposal, acceptance before work, payment tied to demonstrable milestones, and written approval for anything outside the agreed scope. The scope itself is shaped with you during Discovery.
See the workflow move from lead to production
Discovery turns a business problem into a buildable scope
A custom business system cannot be priced or designed accurately from a short description alone.
Two companies may both say they need a CRM, client portal, automation, or a new website, while the actual work behind those words is completely different.
One business may already have clean customer data, established workflows, usable integrations, and a clear process. Another may have years of records spread across spreadsheets, inboxes, disconnected software, and informal routines that exist only in the team's memory.
Discovery is where those differences become visible.
The purpose is not to sell a longer project.
The purpose is to understand what already exists, what should stay, what should connect, what should be replaced, what data needs to move, and which workflows are actually important enough to build around.
That information becomes the basis of the written scope. It also helps prevent two common problems in custom development: paying for functionality the business does not need and discovering important requirements only after development has already started.
The final proposal is therefore based on a defined operating problem and an agreed implementation scope rather than a guess made during an introductory conversation.
Request
You create a free account and answer a short questionnaire about the business. There is no sales call before this: the questions are the conversation.
Review
We read the answers and decide whether this is something we can build well. If it is not, we say so.
Discovery, $600
A paid working session that maps your current tools, records, and gaps and produces the scope. The fee is credited in full toward implementation.
Proposal
A written scope, the total, the payment schedule, and the third-party services you will pay providers for directly. Nothing starts before you accept it.
Build, 40 / 30 / 30
40% at start after the Discovery credit, 30% at the staging milestone, and 30% after final acceptance.
Final review and launch
You review a version-bound package and either accept it or send written change requests. Launch follows final acceptance and final payment.
Warranty and support
60 days of warranty from final acceptance, then a support plan from $490 per month or hourly work at $120 per hour.
Common questions
Why is there no price on the first call?
Because a price before Discovery is a guess. Public Starting From figures show the budget range; a personalized estimate follows the questionnaire and requires a free verified account.
What happens if the scope changes mid-project?
A change order is written, priced, and approved separately, and it is paid in advance before the extra work starts. Work never quietly expands into an invoice you did not agree to.
When do I actually pay?
$600 for Discovery, then 40% at start reduced by that credit, 30% at the staging milestone, and 30% after final acceptance. Invoices are paid externally; nothing is charged on this site.
What if I am not happy with the result?
Final acceptance is a decision you make against a specific version. You can send written change requests instead of accepting, and a corrected version restarts the review period.
Start at stage one
A free account and a short questionnaire. No sales call before it, and no obligation after it.