Globaprom.

How We Work: 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.

This page is for the operations leader or business owner commissioning a build, often for the first time. It shows 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.

Flat vector illustration of a winding path rising across six stepped blocks from an open speech bubble to a raised flag at the top

The Process at a Glance

  1. Scoping call: 30 minutes, free, no preparation required.
  2. Written scope and fixed-price proposal: one figure, one delivery date, a few business days after the call.
  3. Build sprints: AI-assisted development with human review of every line.
  4. Your review and acceptance testing: you test against criteria you already approved.
  5. Launch and handover: deployment plus the full source code, repository, and documentation.
  6. Optional maintenance: a fixed-fee care plan, never required.

Most builds run two to six weeks from approved scope to production. Each step below states its own timeline.

Step 1. 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: who uses the process, which systems it must talk to, which languages your users work in, what "done" looks like. Risks (tricky integrations, data migration, compliance requirements) get named on this call, not discovered mid-build.

  • What you do: bring the person who knows the workflow best, and show us how the work happens today.
  • What we do: run the call, translate the pain into candidate scope, and flag risks early.
  • Timeline: 30 minutes. The call is free and carries no obligation: tell us what you need built to book one.

Step 2. Written Scope and a Fixed-Price Proposal

After the call, we write the scope: the screens, workflows, integrations, languages, and acceptance criteria of your software, in plain English. Attached to it is one fixed price and one delivery date. Not an estimate, not a rate card: a figure.

You read the scope and correct anything we got wrong. Only when it matches your reality do you approve it, and nothing is billed before that approval. If the scope changes later, we quote the change explicitly and you decide before any cost is incurred. The original figure never silently grows.

  • What you do: review the scope, correct it, approve it. The document is yours to keep either way.
  • What we do: write the scope, commit to a price and a delivery date against it.
  • Timeline: most quotes go out within a few business days of the call. Complex scopes (several systems or languages) take longer, and we tell you the quote date on the call.

What moves a quote up or down (integrations, localization, compliance) is documented on the pricing page.

Step 3. Build Sprints: AI-Assisted Development, Human-Reviewed

The build is where AI-assisted development (vibecoding) earns the timeline. Our engineers direct AI coding tools to generate the software, then review, test, and harden the output. The generation is fast; the accountability stays human. Every line of code is reviewed by an engineer before it ships. Architecture, security, and edge cases are review decisions, not model output.

We work in short sprints, and you see working software as it grows: a check-in per sprint, not a single reveal at the end. Feedback that fits the approved scope is folded in while it is cheap to act on. Feedback that goes beyond it is welcome too: we quote it as a change, and you decide.

  • What you do: join a short check-in each sprint and answer domain questions when they surface. No daily standups, no requirement workshops.
  • What we do: generate, review, test, and harden the code; demonstrate working software at every check-in.
  • Timeline: 2–3 weeks for a workflow automation, 3–6 weeks for a custom web app, 5–8 weeks for a multilingual platform, all measured from approved scope.

Step 4. Your Review and Acceptance Testing

Before launch, the software has to pass your test, not ours. The acceptance criteria you approved in Step 2 now 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.

This is deliberately boring. Because the criteria were written down before the build, acceptance is verification, not negotiation. Anything that fails a criterion, we fix at no cost. Anything you want beyond the criteria is a change request, quoted before it is built.

  • What you do: run your real work through the software and mark each criterion pass or fail.
  • What we do: fix every failed criterion, and stage the launch once the list is green.
  • Timeline: you set the pace. The checklist format keeps review a matter of days of effort, spread however your team needs.

Step 5. Launch and Handover: You Own the Code

We deploy the software to production (in your cloud account or ours, whichever the scope specifies) and 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. You can hire any developer, or your own IT team, to take it from here. The documentation is written for exactly that reader. That policy is deliberate: software you cannot leave with is software you rented, whatever the invoice said.

  • What you do: receive the repository and documentation; decide who operates the software from here.
  • What we do: deploy, transfer every asset, and remain reachable for the handover questions.
  • Timeline: launch and handover complete the delivery date quoted in Step 2. They are inside the fixed price, not extras.

Step 6. Optional Maintenance and Support

After handover you choose: run the software yourself, or take a care plan. Care plans cover hosting, monitoring, and small changes for a fixed monthly fee, and they are never required. Because you own the code, the software keeps running either way, and you can move maintenance in-house at any time.

Many clients take a plan for the first months and then decide with real usage data. Others hand the repository to their IT team on day one. Both are normal exits from this process, and neither is penalized.

  • What you do: pick an operating model: care plan, in-house, or a third party.
  • What we do: state the care plan's monthly fee and coverage in writing before you choose.
  • Timeline: monthly, cancelable; details live on the maintenance page.

Quality and Security: What We Actually Do

No badge wall here, just the practices behind every build, stated plainly:

  • 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.
  • 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. Penetration testing is not part of the standard build; we help you arrange an independent assessment if your project needs one.
  • 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. We claim no certification we have not earned.
  • Confidentiality as habit. We spent 20 years in the translation industry handling confidential legal and medical material; NDA-first workflows are our native environment.

Frequently 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. We turn that into a written scope; writing it 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: we do not need your team in daily standups or long requirement workshops.

Can we see the software before it is finished?

Yes. You see working software during the build at each sprint check-in, not a single reveal at the end. Feedback arrives while it is cheap to act on; anything beyond the written scope is quoted explicitly before it is added, so mid-build ideas never inflate the invoice.

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. Care plans cover new changes and operations, never fixes to what we delivered wrong.

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 process assumes you have none: 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

Every project on this page began the same way: someone described a workflow that hurt, in plain language, on a short call. The call is free, the quote is free, and the written scope is yours to keep whatever you decide.