Six services, one way of working.
Websites, WordPress, apps, business software, and the care and speed work that keeps them good. Different crafts, the same method: a conversation, a figure in writing, something real to look at early, and a build that is yours the day it ships. This page is that method, and where each service starts.
Free, in writing
Scope and figure before work
Real by stage two
A browser, a phone, a click
Yours, entirely
Source, data, domain, accounts
Told when not to
"You do not need this"
What we build and look after
Start from what you need, not from what we sell.
Each opens the page written for that kind of work, with its own process, its own honest part and its own questions worth asking.
- Website design We build it for you. Read the page
- WordPress development Builds and rescues. Read the page
- Security & maintenance Updates and repairs. Read the page
- Speed & performance Measured, then faster. Read the page
- Mobile apps iOS and Android. Read the page
- Software development Business systems, SaaS. Read the page
The method
Five stages, and you know where you are in all five.
No portal to log into, no ticket queue, no discovery-phase invoice. The first two stages cost nothing and end with something you can take elsewhere.
- 01 A conversation Half an hour on what the thing has to achieve, for whom, and what it would replace. Describe what you want it to do rather than what you want it to be; deciding what it should be is the work.
- 02 A figure, in writing A fixed scope, a fixed figure and a real timeline, before anybody starts. Free, and yours to take to somebody else. For a site somebody else built, this stage is a report of what we found.
- 03 Something real, early A design in a real browser on a real phone rather than a picture of one. A test build of the app on your own phone. Something to click in the software. This is where a change of mind costs nothing.
- 04 Built in slices you can try From the first commit, in your repository, with the content you send actually in it. Written light, tested where it pays, and read by you as it lands rather than unveiled at the end.
- 05 Launched, handed over, kept Domain, hosting, mail and certificate connected; store review and crash reporting for an app; the handover done as a working session. Then a schedule: updates staged and applied, backups taken and restored, a note each month.
In every build
What we consider part of the job.
None of the following is a tier, an add-on or a line on the quote. They are what makes something somebody can still work on in three years, whether or not that somebody is us.
Yours, entirely
The domain, the content, the design, the source, the data and the store accounts, under your names from day one. No lock-in clause, no hostage hosting, no export fee.
Hosted where you choose
Our own infrastructure, or your cloud account, and moved between them without a rewrite, because nothing in the build assumes where it lives.
Secure by default
HTTPS everywhere, current software, named access rather than shared logins, and a restore point before every change.
Backups that have been restored
A backup nobody has restored is a hope. Restores are rehearsed, so the day one is needed is not the first time it is tried.
Usable by everyone
Readable contrast, a keyboard path through every interaction, markup a screen reader can follow, and every state of a screen designed, including the empty and the broken ones.
It tells you when it breaks
Errors, crashes, downtime and slow requests reported somewhere a person looks, from the first release rather than after the first bad week.
The honest part
Sometimes the right answer costs us the project.
Every studio has a commercial reason to recommend the bigger thing. Here is what we say instead, in writing, before you have paid for anything.
"You do not need this"
An app that would be opened once is a website. A system that three tools already do is configuration, not development. If that is the answer, it is the answer we give, with the reasoning.
Build it, buy it, or keep the spreadsheet
Custom software earns its keep when the process is the advantage, when several tools are pretending to be one, or when the software is what you sell. Otherwise we say which product to buy.
Native, cross-platform, or a web app
Native when the device is the point, cross-platform when the product is, a web application when neither is. The third is often right and rarely recommended. We recommend it when it is.
A redesign is a new project
Maintenance covers keeping software current, backups, certificates, uptime and the small changes a real business needs. When a request has become a redesign we say so, rather than let it drift into the monthly note.
Questions
Before you decide.
Nothing, and neither does what comes out of it: a fixed scope and figure in writing for a build, or a written report of what we found for a site somebody else made. Both are yours to act on with somebody else. There is no discovery-phase invoice on any of the six services.
You do, all of it, from the first day: the domain, the content, the design, the source in your repository, the data in your database and the store accounts under your name. If we stop working together we hand it over and help you move it. There is no clause anywhere that makes leaving expensive.
The honest answer is that it depends on how quickly content and decisions arrive, because that is what holds most projects up. The written quote carries a real timeline for your scope and it is a commitment, not an estimate quietly revised later. In every service you see something real by the end of the second stage.
Yes, and it is most of what the care and WordPress services do. It starts with a look at the site as it stands, then a written report of what we found and what it would take. Existing addresses keep working, and nothing goes dark while we move it across.
Then that is what we write, with the reasoning: a website instead of an app, a product to buy instead of software to build, a web application instead of two store listings. A studio that cannot say "you do not need this" is a studio you cannot trust when it does not.
If you want us to. Care is a schedule, not an adjective: updates staged on a copy and then applied, backups taken and restored, certificates renewed, monitoring connected, and a note each month saying what was done. For an app it also means the yearly iOS and Android releases and their SDK deadlines.
Tell us what it has to do.
Half an hour, then a scope and a figure in writing that are yours to take anywhere. If the right answer is not to build it, that is what we will write.