Do you have a project in your
mind? Contact us.
Contact Us
Custom apps and software
Custom software
Building the thing that does not exist yet
Some work does not fit a product you can buy. The process is specific to how your business runs, or the tools that come close would need so much configuration that you end up maintaining something custom anyway.
We build web applications and internal tools, host them, and hand over something a different developer could pick up without ringing us.
Internal tools
The system your operations team runs on when the spreadsheet has stopped coping. Usually a database, a way to see and edit what is in it, permissions, and connections to whatever else you already run.
Customer facing software
A portal, a booking flow, or a product your customers use directly. The bar is higher: it has to survive people who did not read any instructions, and it has to keep working when you are not watching it.
Tools and systems
What we work with
Front end
Back end
Data
Hosting and delivery
What to expect
How a project runs
Scoping
What the software has to do, who uses it, and which parts matter first. We push to cut the first release down, because the fastest way to learn what is actually needed is to put a small version in front of the people who will use it.
The data model
What the system stores and how those things relate. Getting this wrong is expensive to correct later, so it gets agreed before much is built.
Deciding the business logic
The rules, the permissions, and the exceptions. Who can approve what, what happens to a record when someone leaves, and which states something can move between. These are your decisions and they need naming rather than assuming.
Build in slices
Working software in usable pieces rather than one delivery at the end. Each piece is something you can try, which is also how the scope stays honest.
Testing
Automated tests on the logic that would be expensive to get wrong, and a run through with the people who will actually use it. Both find different problems.
Deployment and access
Where it runs, who can reach it, how accounts are created and removed, and what the backups are. Boring, and the part most often left until the week before launch.
Handover
The repository, the deployment process, documentation, and whatever a different developer would need to pick this up. If you want to take it in house or hand it to someone else, that should be straightforward.
Scope
When you should not hire us
- If a product already on the market does eighty per cent of it, buy that and let us connect it to the rest of your systems. That is almost always the cheaper path.
- If what you need is a website rather than an application, this is not the right service and we will say so.
- If nobody internally can own the software once it exists, building it will create a problem rather than solve one. That is worth settling before starting.
Where enquiries usually go next