Process

Know what is being decided, built and measured

The main risk in custom software is not technical. It is spending months before anyone can tell whether it is working. This is how we prevent that.

Before we start

Who this works for

Good fit

  • A process you can describe and someone who owns it.
  • A cost, delay or risk you can put an approximate number on.
  • A decision-maker available for one hour a week.
  • Willingness to start with a small, paid, scoped step.

Poor fit

  • A fixed price for an unspecified scope.
  • Anonymous developers rotated through a project with no one accountable.
  • A deadline that is already impossible before work starts.
  • A project where no one internally can make decisions.

Four stages

Diagnose → Prove → Build → Improve

Each stage has a named output and an explicit decision at the end of it. Any of them can end the engagement without wasting what came before.

  1. Diagnose

    We sit with the people doing the work, map the process as it actually runs, and quantify where it costs time, money or customers. Then we rank the opportunities against effort and risk.

    Process map, opportunity and risk analysis, prioritised recommendation.

    Decision: which single problem is worth proving first — or that none are.

  2. Prove

    We build the smallest thing that tests the riskiest assumption, connected to real data where possible, with success criteria written down before we start.

    Prototype or production-connected pilot with explicit success criteria.

    Decision: proceed to build, adjust the approach, or stop.

  3. Build

    We deliver in increments you can put in front of real users. Each increment is tested, deployed and documented rather than accumulated for a single launch.

    Incremental releases, automated tests, deployment pipeline and documentation.

    Decision at each increment: ship, extend, or reprioritise the backlog.

  4. Improve

    After launch we measure what changed, support what is running, and decide what the next increment is worth. Sometimes the answer is nothing.

    Analytics, agreed support arrangement, next-increment recommendation.

    Decision: continue, hand over, or close the engagement.

How the working relationship runs

  • A weekly demonstration of working software — not a status document.
  • One shared backlog you can see and reprioritise.
  • A written decision log, so a choice made in week two is still explicable in week ten.
  • A named owner on our side and a named decision-maker on yours.
  • Your repository, your infrastructure accounts, your IP — handed over as part of delivery.

Policy

How Holonera uses AI

We use AI to accelerate analysis, implementation and testing where it is appropriate. Architecture, security decisions, review and accountability remain human-owned.

In practice that means AI assists with drafting, refactoring, test generation and research. It does not choose your architecture, approve a security decision or sign off a release. Where a workflow we build for you uses AI, we will show you its failure modes and the human review path before it goes live.

Commercial model

How engagements are priced

Every stage above is delivered through a fixed-price, scoped or ongoing engagement format, each with its own indicative pricing.

See engagement formats and pricing

Common questions

How quickly can you start?

Discovery work can usually begin within a few weeks. We will give you a specific date rather than a general reassurance, and we will not start a build we cannot staff properly.

What happens if the pilot fails its success criteria?

We say so, in writing, with what we learned. The criteria are agreed before the pilot precisely so that this conversation is factual rather than defensive.

Who is actually doing the work?

Product and technical accountability stays with the founder. Where an engagement needs a specialist he does not have, he adds a trusted contractor and tells you who they are and what they are responsible for.

Do you sign NDAs?

Yes, before any detail about your business or systems is discussed.

Start with the diagnosis, not the build.

Tell us what is happening today. If a two-week analysis is the right first step, we will propose exactly that.

Tell us what you need