Three ways to get a platform
When a business needs software, there are three broad routes. Each is right for someone.
- Buy. A ready-made product: a booking system, a membership service, an e-commerce platform. You pay a subscription and fit your process to it.
- Bolt together. Several products joined with automation tools and some glue code: a form tool feeding a spreadsheet feeding an email service.
- Build. Software written for your business, on a framework, hosted where you choose.
When to buy
Buy when your process is close to everyone else's. Booking a haircut, selling products, running a newsletter: these are solved problems with good products. Buying gets you running quickly, and someone else handles the security patches.
Before you commit, check three things: can you export all your data, in a useful format, whenever you like? What will it cost at three times your current size? And what happens to your customers if the product is discontinued or bought?
When to bolt together
Joining tools is a sensible way to test an idea or run an internal process. It gets awkward when the joins become the business. Each tool holds a piece of your data, each has its own idea of who a customer is, and when something breaks between two of them, nobody owns the gap. If you find a person reconciling three systems every Monday, the joins have become the product.
When to build
Build when the rules that make your business different are the rules the software has to follow. A collection round that has to be re-ordered when a stop is added, but never move a stop that is already collected. A city guide where one change to a venue must update five websites. A game whose rounds are built from a fixture list. These are the things off-the-shelf products get nearly right, which is often worse than wrong.
Building costs more up front and needs looking after. In return you own the code, the data and the decisions, and the software fits the business instead of the other way round.
If you build: what we build on, and why
Any mature stack can work. What matters most is that you can still run it, hire for it and upgrade it in five years. Here is what we use and why.
- Laravel (PHP). A mature framework with queues, scheduling, email, authentication and testing built in, a large community and plenty of developers who know it. Our live platforms run Laravel 13. More on Laravel development.
- Server-rendered pages, with interactivity where it earns it. Content pages are rendered on the server, which is fast and good for search. Where an interface needs to behave like an app, we add Vue or React through Inertia, as on PLZ and SIT.
- A database chosen for the job. MySQL for busy shared data, Postgres where its features help, SQLite for simpler apps where one file is easier to back up and move.
- Specialist services for specialist jobs. Stripe for payments, Postmark for email, a CDN in front of everything. We build what is specific to you and rent what is not.
- Self-hosting where renting is the risk. Map tiles and road routing are both things we run ourselves on some platforms, so that a supplier changing its prices or rules cannot take them away.
Questions that decide it
- Which rules are specific to us, and could a product follow them?
- Where does our data live, and can we get it all back?
- What will this cost to run in three years, not just to build or buy this year?
- Who looks after it, and what happens if they leave?
- What is the smallest version that would be useful?
The last question is the most useful. Whatever route you choose, start with the smallest thing that does a real job, and grow it.
If you would like a second opinion on a buy, bolt or build decision, get in touch. Sometimes the honest answer is to buy.