← HEYGUS

You will know the price and the plan before you commit to anything.

Most software projects go wrong in the same two places: nobody agreed what was being built, and nobody saw it until it was finished. This is arranged so neither can happen.

The engagement

Four steps, and you can stop after the second.

There is no discovery phase you pay for before you know what you are getting.

A call

Half an hour. You describe the part of the week that should not still be manual. We ask about the systems involved and who touches what. You get an honest view of whether it is worth building, including when it is not.

A written scope

What gets built, what it costs, how long it takes, what it connects to, and what is deliberately not included. A fixed price, not an estimate that drifts. You read it before anything is agreed and you owe nothing if you walk away.

The build

Small releases you can actually use, not one delivery at the end. You see it working early enough to change your mind while changing it is still cheap. Nothing goes near your live system until it has been proved somewhere safe.

It is yours

The code, the documentation and the accounts are in your name. Support afterwards if you want it, on terms agreed in writing, and nothing stops working if you do not.

Terms in plain words

What you end up owning, and what you never get billed for.

You keep

  • The source code, in a repository in your name.
  • The documentation, written as the work is done rather than assembled at the end.
  • The hosting, database and third-party accounts, in your company's name and paid by you directly.
  • The right to take all of it to another developer at any point, without asking.

There is no

  • Licence fee that keeps running after the work is finished.
  • Component that stops working if you stop working with us.
  • Paid discovery phase before you know the price.
  • Change that lands on your live system without you knowing it is coming.
While it is being built

You are handing over the systems your business runs on.

So these are not preferences. They are how the work is done, on every engagement.

Never on production

  • Work happens in a staging environment. If one does not exist, building one is the first task.
  • Nothing touches live bookings, billing or customer records until it has been tested where it cannot do harm.
  • Changes go out small and reviewed, because this is a live business handling real customers' money.

Tests on what must not break

  • Pricing calculations, because an error there is money.
  • Reference and identifier uniqueness, because collisions are very hard to unpick later.
  • Access control, so the wrong person cannot see the wrong thing.
  • Payment handling, every time.

Personal data handled properly

  • UK GDPR applies to identity documents, customer messages and location data alike, and it is treated that way.
  • Encrypted storage, access logging, and retention rules that actually run rather than sit in a policy.
  • No unnecessary copies. Never a production database on somebody's laptop.
  • A data processing agreement in place before any of it starts.

Written down as it goes

  • Documentation produced alongside the code, not promised for the end and then rushed.
  • Decisions recorded with the reasoning, so the next person understands why rather than guessing.
  • An escalation route agreed at the start rather than improvised during the first problem.
The delivery model

You talk to the person writing the code. Every time.

HEYGUS is one accountable engineer working with AI development tooling. There is no account manager between you and the work, no internal handover, and no requirement that gets lost on its way from the person who heard it to the person building it.

That is faster and considerably cheaper than an agency team, and it is how a growing number of professional software companies now build. It also means the person quoting the work is the person who has to deliver it, which tends to keep quotes honest.

It is a small operation and we take a small number of engagements at a time. If we cannot start when you need us, you will be told that on the first call rather than after you have signed something. Everything is documented as it is built and the accounts are in your name, so you are never dependent on us being available.

Before you ask

The questions everybody asks on the call.

What does it cost?

A fixed price, quoted after a written scope. We do not give a number before we understand the systems involved, because any number given at that stage is a guess, and guesses get corrected upwards later. The scope and the price come before you commit to anything.

How long does it take?

The scope says so before you agree to it. Work goes out in small releases rather than one delivery at the end, so you see something working early and can change direction while it is still cheap to do.

Do I own what you build?

Yes. The code, the documentation and the accounts are yours, in your name. There is no licence to keep paying and nothing stops working if you stop working with us.

Will you be working on our live system?

No. Work happens in a staging environment, and if one does not exist then building one is the first task. Nothing touches live customer data, bookings or billing until it has been tested somewhere it cannot do harm.

Do you replace the systems we already have?

Usually not. Most of the work is making what you already own talk to itself. Replacing a working system is expensive, disruptive, and rarely the actual problem.

What if the honest answer is that we should not build anything?

Then that is what you will be told on the call. Some problems are a process problem, or a training problem, or a setting that nobody ever switched on. Selling you a build in those cases would be easy and wrong.

The first call costs nothing and commits you to nothing.

Half an hour. Describe the bit of your week that should not still be manual, and we will tell you honestly whether it is worth building.

Book a call

No sales deck, no obligation, and a straight answer either way.