Our Software Development Process in Six Steps
Buying custom software usually means trusting an agency's black box: hourly billing, vague milestones, and a delivery date that moves. Our software development process removes the box. Six steps, each ending in something you approve, from a 30-minute scoping call to a handover where you own every line of code.
Commissioning a build, often for the first time, raises the same questions for every operations leader and business owner: what we do at each step, what you do, and how long it takes. For the catalog of what we build, see our custom software development services. For the numbers, see how our fixed-price packages work.
The process at a glance
Most builds run two to six weeks from approved scope to production.
Scoping call: 30 minutes, free.
Written scope + fixed-price proposal.
Build sprints, human-reviewed.
Your review & acceptance testing.
Launch & handover: you own the code.
Optional maintenance: never required.
The six steps in detail
The scoping call: your problem in plain language
Everything starts with a 30-minute call. You describe the workflow that hurts: the spreadsheet everyone fears, the orders re-keyed into the ERP, the documents assembled by hand. A rough idea is enough; most clients arrive with a pain, not a specification. We ask the questions that make the pain buildable and flag risks early.
Written scope and a fixed-price proposal
After the call, we write the scope: the screens, workflows, integrations, languages, and acceptance criteria, in plain English, with one fixed price and one delivery date. You read it and correct anything we got wrong. Nothing is billed before you approve it.
Build sprints: AI-assisted development, human-reviewed
The build is where AI-assisted development (vibecoding) earns the timeline. Engineers direct AI coding tools to generate the software, then review, test, and harden the output. Every line of code is reviewed by an engineer before it ships. You see working software grow, a check-in per sprint, not a single reveal at the end.
Your review and acceptance testing
The acceptance criteria you approved in Step 2 become a checklist. You work through the software, ideally with real data and the people who will use it daily, and check the criteria off. Anything that fails a criterion, we fix at no cost.
Launch and handover: you own the code
We deploy the software to production, then hand over everything: the full source code, the repository, the deployment configuration, and the documentation. Ownership is total. No licenses, no per-seat fees, no dependency on Globaprom to keep the software running.
Optional maintenance and support
After handover you choose: run the software yourself, or take a care plan covering hosting, monitoring, and small changes for a fixed monthly fee. Never required: you own the code, so the software keeps running either way.
No badge wall, just the practices behind every build
Human review of all AI-generated code
An engineer reviews every line before it merges. This is the core quality control of AI-assisted development, and the reason it is safe to buy.
More on AI-assisted development
Automated checks behind the human review
Dependency scanning runs automatically on every push and pull request (Dependabot plus a CI audit of production dependencies), so a package with a known moderate-or-higher advisory fails the build before launch.
Integrations that fail loudly
Every integration ships with error handling, retries, logging, and monitoring. A connector that fails silently costs more than no connector.
Access control by default
Web applications include authentication and role-based permissions as standard scope, not add-ons.
Compliance scoped in writing
GDPR data handling, PCI DSS scope control, audit trails: each is named in the scope and priced explicitly, never discovered mid-project.
Confidentiality as habit
We spent 20 years in the translation industry handling confidential legal and medical material; NDA-first workflows are our native environment.
Our translation heritageFrequently asked questions
What do we need to prepare before the scoping call?
Nothing formal: no specification, no technical documents. Bring the person who knows the workflow best, plus examples of what the process runs on today: the spreadsheet, the forms, the emails. Writing it into a scope is our job, not yours.
How much of our time does a build take?
Your involvement concentrates at the start and end: the 30-minute scoping call, a scope review, a short check-in each sprint, and acceptance testing before launch. The build itself runs without you.
Can we see the software before it is finished?
Yes. You see working software at every sprint check-in during the build. Anything beyond the written scope is quoted explicitly before it is added.
What happens if we find a bug after launch?
We fix it at no cost. If the software does not behave the way the written scope and acceptance criteria say it should, correcting it is part of the build, not a maintenance charge. With a premium care plan, this post-launch defect coverage extends up to 60 days from launch.
Do we need technical staff on our side?
No. The scope is written in plain English, we handle deployment and hosting, and handover includes documentation your next developer, or ours, can pick up. If you do have an IT team, we work in their repositories and hand over to them directly.
Start With the 30-Minute Call
Describe the tool, automation, or application you need. We reply with a fixed scope, a fixed price, and a delivery date measured in weeks, every line reviewed by a senior engineer before it reaches you. Scoping a repetitive process instead? See what's possible in workflow automation for operations teams. Founders scoping an MVP get the same process on the same timeline: see custom software development for startups.