Skip to content
SOFTRIZQSoftrizq home

How we build

The practices, written down

Most studios describe their process in a sentence and hope nobody asks. Ours is published, because it is the actual reason to hire us — and because a studio that cannot describe how it works usually does not have a method.

Practice

Seven things we do on every project

None of them are optional and none are billed as extras. They are the reason a client can hand our work to a different team without a rewrite.

  1. 01

    Specification before code

    Projects start from a written requirements specification rather than a feature list. Every requirement gets an identifier.

    It costs time at the start, when the pressure to show visible progress is highest. It saves considerably more later, because there is a single document that says what the system is supposed to do — and a way to check whether it does.

  2. 02

    Requirements traced into the code

    Each requirement identifier is cited in the code comment where that requirement is satisfied.

    The rule is short enough to remember: if the code and the specification disagree, one of them is a defect. Not a discussion — a defect, which somebody fixes. It removes an entire category of argument, and it turns an audit question into a search.

    // FR-REG-039: registration numbers are allocated in sequence
// and must never collide, even under concurrent submission.
const next = await allocateRegistrationNumber(tx, intakeId);
  3. 03

    Nothing merges unreviewed

    Every change is reviewed before it lands, including changes written by whoever is most senior on the project.

    Review is not about catching mistakes so much as making sure more than one person understands each part of the system. That is what stops a project depending on one person's memory.

  4. 04

    A QA pack you can re-run

    Projects ship with a written test pack your own team can run after any future change — including changes we did not make.

    Most handovers give you working software and no way to tell whether it still works six months later. The pack covers requirements, permissions, data integrity, accessibility and performance, with each item marked pass, fail, or not applicable with a reason.

  5. 05

    Role-based manuals, not one generic PDF

    Where a project has distinct kinds of user, each gets its own written guide.

    On the last learning platform that meant four: administrator, super-administrator, instructor and student. A single manual covering everyone is read by no one.

  6. 06

    Changes priced before they are built

    Anything outside the agreed scope gets a written change order with a number, before the work happens.

    This is the single habit that prevents most disputes between a studio and its clients. It also means you always know what something costs while you can still decide not to have it.

  7. 07

    Documented handover, and you own everything

    Deployment documentation, environment notes, a licence inventory, a recorded walkthrough, and an honest list of known limitations.

    Full intellectual property transfers on final payment, written into the contract. Making ourselves replaceable is deliberate — it is what makes us worth hiring in the first place.

Security

We follow a written baseline on every project and can evidence each item. If you send a security questionnaire, you will get it back within a day rather than a fortnight.

  • Secrets never committed; rotated when anyone leaves a project
  • Least privilege, two-factor mandatory, access removed on the warranty end date
  • Authorisation checked server-side on every request
  • Dependencies scanned in CI, with a licence inventory at handover
  • Backups automated — and a restore actually tested before handover
  • Every service in your account, not ours. We hold no data after handover

What we do not do

Being straight about the gaps has never lost us a project. Being caught overstating one would.

  • No SOC 2 or ISO 27001

    We follow the practices above and can evidence each one. We do not hold a certification and will not imply otherwise.

  • No in-house penetration testing

    We can arrange an independent third party where a project requires it.

  • No 24/7 on-call by default

    Available on a retainer. Not included in a fixed-price build.

Send us your security questionnaire

Or just tell us the problem. Either way we reply within one working day.

Book a callhello@softrizq.com