Software. Security. With prices you can actually see.

Because domain pricing depends on the extension and the registrar. A .com, a .mv and a .org are not the same price, and quoting one number here would be wrong for most people reading it. You buy the domain on your own account and it stays yours.

Because infrastructure requirements vary enormously between projects. A static site costs close to nothing to host; an application with a database, background jobs and real traffic does not. You pay the platform for what you actually use, at their price, on your account.

Because there is more engineering in it. A static deployment is a build configuration, a domain and a certificate. An AWS deployment can involve compute, networking, IAM, databases, VPCs, security groups, load balancing, deployment automation, monitoring and backups. The fee reflects that work, and it is separate from whatever AWS then bills you for running it.

Yes, where the architecture allows it. Some builds are portable enough to run anywhere; others depend on a specific platform, and we will tell you which yours is before you commit to anything. If you want to run it yourself, we will hand it over set up to do that.

Yes, subject to a look at the codebase first. We need to see what is there before we can say what a change will take — and occasionally the honest answer is that it should be replaced rather than extended, in which case we will say so.

Because the feature is rarely the expensive part. Before we can safely change software we did not write, we have to understand its architecture, its database, its authentication, its business logic and its dependencies, then work out where the new thing fits, build it, test it against everything it touches, and release it without breaking what already works. That is the work you are paying for.

No. Without it a system keeps running and nobody is watching it: updates stop, security fixes go unapplied, and when something breaks you are starting from scratch with whoever is free. For a small static site that can be a reasonable risk. For anything taking payments or holding customer data, we would rather you had it — or had someone else doing it.

Maintenance is keeping what exists working: updates, fixes, monitoring, small content changes and support. If a request makes the system do something it could not do before, that is a feature. Small features are quoted on their own; larger ones become a feature-integration or custom-software project. We tell you which one it is before we do it.

No. You hold the provider account and pay their usage charges directly at their rates. That keeps the running cost visible to you and keeps it out of our revenue, which is the only arrangement where we have no reason to send more work to a model than a job needs.

No. The builder adds up published ranges for the things you ticked, which is enough to tell you whether a project is in your range before you talk to anybody. A quote comes after we have gone through the actual requirements with you, and it is what we would put in writing.

Yes, subject to scope, availability, capability and whether it makes commercial sense for both of us. Large custom projects take up significant engineering capacity, so we would rather turn one down than take it on badly.

Scope and price are agreed in writing before anything starts, and projects are staged so you are never paying far ahead of the work. Anything outside the agreed scope is quoted before it is done, not added to an invoice afterwards.