03.01
Websites
Marketing sites, content sites, and landing pages — fast, accessible, and editable by your team.
Index What we do S/03
Software built for how you actually work.
S/03 / Scope
What this covers.
03.02
Internal tools and admin panels
The interfaces your staff use all day, designed for the people who actually use them.
03.03
Web applications
Products with real users, accounts, permissions, and data that has to stay correct.
03.04
Mobile products
Where a phone is genuinely the right device for the job, not where an app is a box to tick.
03.05
Client and partner portals
Giving outside parties controlled access to their own data without email attachments.
03.06
Design and prototyping
Interface design, and a working prototype early enough that changing your mind is still cheap.
Signals
Where this usually starts.
01
A spreadsheet is doing a job it was never designed for, and everyone knows it.
02
You pay per seat for software where your team uses one tenth of the features.
03
Your process doesn't fit any product on the market, so staff maintain the gap by hand.
04
An existing system works but nobody wants to touch it, and nobody remembers why.
05
You have a product idea and need it built properly the first time.
Deliverables
What you get.
Scope and a working prototype
Something you can click before anything expensive is committed to.
The built product
Designed, developed, integrated, tested, and deployed.
Source code and full ownership
The code is yours on final payment, in your own repository, with no licence back to us.
Deployment and environments
Running where you can see it, with a path from staging to production.
Documentation
Enough for another developer to pick it up without calling us first.
Every engagement follows the same four stages — understand, design, build, improve. Scope and price are agreed before anything is built.
How we workQuestions
Asked often enough to answer here.
Who owns the code?
You do. On full payment, ownership of the work we produce for you transfers to you, in your own repository. We retain only our pre-existing tools, libraries, and general know-how — which is standard, and which we set out in writing before starting rather than leaving it to be discovered later.
Can you take over an existing codebase?
Often, yes. We start with a short review to establish what's there, what state it's in, and what it would take to work in it safely. Sometimes the honest answer is that a rewrite costs less than the repair, and we'll tell you if that's the case.
What do you build with?
Chosen per project from what fits the requirements, your team's ability to maintain it, and how long it needs to live. We avoid choices that would leave you dependent on a single unusual technology, or on us.
What happens after launch?
You can take it in-house, we can continue under a retainer, or we can stay available for changes as they come up. Nothing in how we build is designed to make leaving difficult.
Have a project in mind?
Tell us what you're working on and what you need help with. We answer every message ourselves, usually within two business days.