Web Development
Custom web applications and portals
When off-the-shelf software almost fits but not quite, a custom web application closes the gap. We build client portals, booking systems, dashboards and internal tools shaped around how your business actually works.
Who it is for: Businesses running critical work through spreadsheets and workarounds, or paying for software that fights their process instead of fitting it.
Everything in this service
- Discovery and scoping with a fixed-price first phase
- Secure authentication and role-based access
- Clean, documented APIs where systems must connect
- A focused first version, then planned iterations
- Hosting setup, backups and monitoring
What to expect
- A tool that fits your process instead of bending it
- Hours saved on work the app now does
- Software you own, not a subscription that dictates terms
How custom web applications actually works
Scoping version one honestly
Almost every custom software project that fails does so for the same reason. Version one was too big. It took too long, the money ran out or patience did, and the thing never reached real users, which means nothing was ever learned.
The useful discipline is to define the smallest version that lets one real workflow happen end to end, for real people, with real data. Not a demo. A tool someone can genuinely use on Monday morning. That usually means one user type rather than three, one core process rather than the whole department, and manual handling of the edge cases at first. A report that is exported and formatted by hand for the first three months is fine. Building the reporting module before anyone has used the system is not.
The way to get there is to separate what makes the tool work from what makes it nicer. Take the feature list and sort every item into whether the process is impossible without it or merely slower. Everything in the second group waits. This is uncomfortable, because the deferred items are usually the ones someone in the room asked for. It is also the single decision that most determines whether the project ships, and real usage reliably reorders the roadmap anyway. Features nobody asks for once they are using the tool are the cheapest features you will ever avoid building.
- Define one complete workflow for one user type, not a broad partial system
- Sort every request into impossible without it, or just slower without it
- Handle rare cases manually at first, automate them once volume justifies it
- Ship to real users early, real usage reorders the roadmap every time
- Treat the first version as a question you are asking, not a product you are finishing
Authentication and permissions, decided early
Who can sign in, and what each person can see and do, is a foundation decision. Retrofitting a permission model into an application that assumed everyone could see everything is one of the more expensive pieces of rework there is, because access checks have to be added everywhere at once and any missed spot is a data leak.
Start with the roles that genuinely differ. Most systems need fewer than people expect: an administrator, a standard user, and often a limited external user such as a client or contractor. Then define what each role can do to each type of record, including whether they can see records belonging to other people or other organisations. That last question is the important one in any system serving multiple clients, because the failure mode is one customer seeing another customer data.
On authentication itself, use a well-established approach rather than writing your own. Password handling, session management, reset flows and multi-factor support are areas where subtle mistakes have serious consequences, and mature libraries and services have already solved them. If your users already sign in somewhere, connecting to that is usually better than creating another account for them to forget. And enforce permissions on the server, always. Hiding a button in the interface is presentation, not security, because the underlying request can still be made directly.
- Define roles and record-level access before building features
- Be explicit about who can see records belonging to other organisations
- Use established authentication libraries or services, never a homemade one
- Enforce every permission on the server, hiding a button proves nothing
- Plan how access is removed when someone leaves, not just how it is granted
Data modelling and why it is the expensive part to change
The data model is the shape of the information your application stores and how the pieces relate. It is harder to change than any interface, because existing records have to be migrated, and every part of the system that reads or writes that data has to be updated at the same time.
Spend the time up front on a few specific questions. What are the real entities in this business, using the words the business uses. How do they relate, and can one have many of another. Which fields must always be present. What happens when a record is deleted: does related information go too, or should the record be marked inactive and kept. That last one matters more than it sounds. Hard deletion in a business system destroys history that is often needed later for audit or reporting, and marking records inactive is usually the safer default.
Two other things pay for themselves. Keep a record of when things happened and who did them, because the question of who changed this and when arrives in every business system eventually, and it cannot be answered retrospectively if it was never recorded. And resist storing a value that can be calculated, since stored copies drift out of agreement with the source. Where performance demands a stored copy, make it obvious that it is derived and have one clear place responsible for updating it.
- Name entities in the language the business already uses
- Prefer marking records inactive over deleting them outright
- Record who changed what and when, from the first version
- Avoid storing values that can be derived, they drift out of sync
- Expect to migrate data, so write migrations rather than editing by hand
Build or buy, and the middle path most people miss
Building custom software is right less often than agencies pretend and more often than software vendors admit. The honest test is whether the difference between what you need and what the market sells is worth the cost of building and maintaining your own.
Buying is usually correct when a standard product covers the great majority of the requirement, when the process is not a source of advantage for you, and when the gap can be closed by changing how you work. Building is usually correct when your process is genuinely unusual and is part of why customers choose you, when the workaround cost is large and recurring, when you need to hold data you cannot put in a third-party system, or when subscription costs at your scale have grown past the cost of owning something.
The middle path is the one people forget: buy the parts that are solved problems and build only the piece that is actually yours. Authentication, payments, email delivery, file storage, reporting, document generation. All of these are available as services that do the job better than a custom build would, and connecting them is far cheaper than recreating them. A well-scoped custom application is often a thin layer of your specific logic over several bought components, and that is a good outcome rather than a compromise.
- Buy when a product covers most of it and the process is not your advantage
- Build when the workaround cost is real and recurring, or the process is the edge
- Buy the solved parts: payments, auth, email, storage, reporting
- Count the ongoing cost of ownership, not just the build price
- A good custom app is usually a thin layer of your logic over bought pieces
Technical debt: what it is and when it is worth taking on
Technical debt is the accumulated cost of choices that made sense at the time and now slow things down. Some of it is deliberate, taken on knowingly to ship sooner. Some of it is just entropy, the natural result of a system that has grown past the assumptions it was built on.
Deliberate debt is a legitimate tool. Hard-coding something that will vary later, skipping automation for a rare case, or building a simpler version of a feature to see if anyone uses it. What makes it debt rather than damage is that it is written down and revisited. An undocumented shortcut becomes a mystery within a few months, and nobody can tell whether it was a decision or a mistake.
It becomes a problem when it starts affecting delivery: small changes take much longer than they should, the same bug returns in different guises, or developers avoid touching a particular area. Those are the signals to spend time repaying it rather than adding features. The practical approach is continuous rather than occasional. Reserve a share of each cycle for improvement, and clean up the area you are already working in whenever you touch it. Large rewrite projects to clear debt are usually a sign it was left far too long, and they rarely go well.
- Record every deliberate shortcut with the reason and the trigger to fix it
- Watch for the signals: slow small changes, recurring bugs, areas people avoid
- Reserve part of each cycle for repayment rather than saving it up
- Improve the code you are already touching, that is the cheapest moment
- Treat a proposed full rewrite as evidence the problem was ignored too long
Handover and documentation: the test of who really owns the software
You should be able to move a custom application to another developer without drama. If you cannot, you do not own the software in any meaningful sense, whatever the contract says. Building for that outcome from the start also produces a better-run project, because it forces things to be written down while they are fresh.
The minimum handover is the full source code in a repository you control, access to every hosting, database and third-party service account in your own name, and instructions that let a competent developer get the project running locally and deploy a change. That last part is the real test. If getting the project running requires a conversation with the original developer, the documentation is not finished.
Beyond that, record the decisions rather than just the code. Why this database, why this integration, what the unusual piece of logic is for, what has been tried and rejected. Code explains what happens; only documentation explains why. Add the operational details too: where backups go and how to restore one, what monitoring exists and who gets alerted, which credentials expire and when. And do a live walkthrough as well as writing it down, because a session where the next developer asks questions surfaces the assumptions that no document anticipates.
- Source code in a repository you own, and accounts in your own name
- Instructions good enough for a new developer to run and deploy unaided
- Document decisions and reasons, not just how the code works
- Include backups, restores, monitoring and credential expiry dates
- Do a live walkthrough as well, questions surface what documents miss
A clear path, step by step
- 01
Scope the real problem
We map your process and cut the feature list to what version one truly needs.
- 02
Design the flows
Screens and data models agreed before code, so changes stay cheap.
- 03
Build in slices
Working software delivered in short cycles you can try, not a reveal at the end.
- 04
Launch and iterate
Real usage decides the roadmap. We build what users prove they need.
Why choose us for this
We argue for a smaller version one, because that is what ships
Security and backups from the first deployment
Plain-language progress you can check weekly
Common questions
When is custom software worth it over off-the-shelf?
When the workaround cost is real: hours lost weekly, errors from manual steps, or a process that gives you an edge no product supports. If a standard tool covers 90 percent of it, we will tell you to buy, not build.
What does a custom web app cost?
It depends entirely on scope, which is why we scope a fixed-price first phase before anything else. You get a real number for a real deliverable, not an estimate that doubles.
Who owns the code?
You do. Full source, documentation and deployment access are handed over. You can move to another developer any time, which keeps us honest.
Explore related work
Want this for your business?
Book a free visibility call and I will tell you honestly whether I can help.
How this is delivered
One person leads every project. Where a job genuinely needs a specialist, I bring in people I have worked with before and manage them, so you get one point of contact and one invoice rather than three suppliers blaming each other.
- You talk to the person responsible for the work, not an account manager
- Specialists are briefed and managed by me, and their work is checked before it reaches you
- One contract, one invoice, one place to chase