Plan
The method
One increment per month, one demonstration per milestone, acceptance testing that does not start at the end.
Four movements, and one rule that holds them all together: nothing is presented on slides. What we demonstrate is software running, on your environment, with your test data.
The four movements
01. Framing
before the first line of code
- —Workshop on the chart of accounts and commission schedules
- —Survey of the actual access level available at each partner
- —Ledger data model, validated with your accountant
- —Counter mockups, tested with an actual teller
- —V1 scope agreed and signed
02. Build
two-week sprints
- —A working version deployed to your staging environment at each sprint end
- —A demo of running software, never a slide deck
- —Automated tests on accounting invariants, on every commit
- —Code pushed continuously to your own Git repository
03. Acceptance
your teams, fictional data
- —Test sets built from your real trading days
- —Restore drill: destruction and full rebuild from backups alone
- —Penetration test, report delivered
- —Training for tellers and branch managers
04. Cutover
one counter at a time
- —Short, controlled dual entry on the first branch
- —Daily comparison: AiO balance against your current accounting
- —Gradual rollout once both figures agree
- —Operations documentation and installation procedures delivered
Monthly increments, continuous acceptance
Every month ends with a working version deployed to your staging environment. Your teams work on it continuously from month 3, at a rate of two half-days per month.
You discover nothing at the end. If a direction does not suit you, the cost of correction is counted in days, not months.
Three environments
| Environment | What it is for | Who has access | Opens |
|---|---|---|---|
| Development | Our daily work | The team | M1 |
| Staging | Your validation, fictitious or anonymised data | You and your teams, continuously | End of M2 |
| Production | Your real operations | Your users | M5 for preparation, M6 for users |
No real data passes through the development or staging environments.
What counts as a defect, and what does not
This is the distinction that protects both parties. Without it, any new request can be presented as a defect, and any defect can be deflected as an enhancement.
| Level | Definition | Fix | Effect on the milestone |
|---|---|---|---|
| Blocking | Makes an essential business process impossible with no workable workaround, or damages accounting integrity, or exposes data to an unauthorised person | Taken up within 4 working hours, fixed within 2 days | Suspends the milestone |
| Major | Severely degrades an essential process, but a documented workaround exists | 5 working days | Does not block the milestone |
| Minor | Ergonomics, labels, presentation — no effect on the business result | Next release | None |
Not a defect: functionality outside the frozen scope, a change of need after validation, a preference contrary to an approved mockup, behaviour compliant with the specification but judged unsuitable, a malfunction caused by a third-party service or by configuration made by your teams.
Code ownership
Code is pushed continuously to a repository you own, from the first week. You see every contribution, every day.
The dossier distinguishes three regimes: the custom developments built for you — modules, screens, rules, workflows, charts of accounts, configuration — are assigned to you on full payment; Vortex-Soft's generic building blocks — frameworks, libraries, components, tooling — remain our property, with a perpetual and irrevocable licence for your operation, including by a third party of your choosing; open-source components remain governed by their licences, the list of which is delivered to you.
The system is designed to be taken over by another competent technical team, on the basis of the delivered documentation: architecture, database schema, installation, update and restore procedures.
Opening
You are starting your business: there is no history to migrate, no double entry to eliminate, no accumulated discrepancies to explain. That is one workload less, and it is reflected in the price.
Only the opening reference data is entered — branches, users, networks, fee schedules, chart of accounts — and starting balances are recorded as dated, justified opening entries.
The first counter opens with on-site support on day one. Any further counters open in waves. Before that, the production environment is prepared at month 5 and the timed restore drill is run: we destroy a copy and rebuild it from backups alone, with the ledger trial balance recalculated and compared. The real go-live is therefore not a first attempt.