Start with the problem, not a platform
It is tempting to begin a web project by choosing a framework, theme or a list of plugins. I prefer a different starting point: who will use the tool, what they are trying to achieve and what is currently getting in their way. That usually reveals what the website or application actually needs to do.
For a small business, the valuable result might be a straightforward quote request, a clearer product catalogue or an order process with fewer manual steps.
When a custom tool makes sense
Off-the-shelf software can be excellent. It can also bring complexity that does not match a particular workflow. A small, purpose-built feature may make sense when the process is unusual, when integrations are limited or when staff spend time repeating the same corrections.
Custom does not mean adding everything. The best scope is often a narrower one: a tool that performs a few things very reliably.
Design for the actual users
Readable text, accessible controls, responsive layouts and meaningful confirmation messages should not be afterthoughts. A tool can look impressive in a large desktop screenshot and still be frustrating for someone trying to complete a task on a phone.
I like testing the full journey, including what happens when a file is too large, a required field is missing or a connection fails.
Build with maintenance in mind
Any feature creates responsibilities. Data needs backups; access needs appropriate controls; dependencies need updates; and people need a way to get support when something changes. A smaller and well-documented tool is often easier to keep reliable.
Good documentation is part of the product. So is a setup process that another person can understand months later.
Measure whether it really helps
For every addition, I like to ask what success looks like: fewer back-and-forth emails, faster quoting, a completed order or less repetitive admin work. That keeps development connected to a useful outcome rather than a list of technical features.
The goal is not to write more software. It is to solve the problem with the right amount of software.
Final thought: Every design has trade-offs. The useful part is recognizing them early, testing a workable solution and making the next version better.
These are general maker and software notes based on personal projects, not a guarantee that any particular design will suit a safety-critical application.
← Back to all articles