We build custom software for a living, and we still tell most people to buy first. Ready-made products are cheaper to start, someone else maintains them, and they encode years of other customers’ lessons. The question is not whether custom is better. It is whether the part of your business you want to improve is one a product can serve. Accounting, payroll, email, a basic online shop, a ticketing desk — these work much the same way everywhere. If a product already does 80% of what you need and the rest is preference, buy it and adapt your habits to it. Paying to rebuild a solved problem is the most common waste we see.

Read the full field note →

When estimates for the same project are miles apart, it is rarely because one team is greedy. It is because the brief left room for each of them to picture a different piece of software. A good brief closes that gap, and it does not need to be long. Describe what goes wrong today and what “better” looks like, in business terms: orders lost, hours spent, errors made, customers waiting. A team that understands the problem will often suggest a simpler solution than the one you had in mind.

Read the full field note →

How you pay for a software project shapes how it is run. The two common models each protect a different party from a different risk, and choosing the wrong one for your situation causes more disputes than bad code does. A fixed price suits work that is well understood and unlikely to change — a defined integration, a website from an agreed design, a known report. You know the cost before you start.

Read the full field note →

Connecting two systems is easy on a good day. The work is in the bad days: the other system is down, a message arrives twice, someone renames a field, a sync half-finishes. An integration is only as good as its behaviour when something goes wrong. For every kind of record — customers, items, prices, stock, invoices — name one system as the owner. Others may read it or hold a copy, but changes start in the owner. Two systems that can both edit the same record will eventually disagree, and nobody will know which is right.

Read the full field note →

A field app that needs a connection fails exactly where it is needed most. Property technicians, for example, spend much of the day in plant rooms and basements with little or no signal. Building for that properly is a design decision made on day one, not a feature added later. An offline-first app saves every action on the device first and shows it as done. Sending it to the server is a separate step that happens whenever a connection is available. The person in the field never waits for the network.

Read the full field note →

The day custom software goes live, its real users arrive with real data, and the most useful feedback starts. Planning for what comes after launch is what separates software that improves over the years from software that slowly rots. Automatic backups are standard; restoring from them is not. Choose hosting with point-in-time recovery, and test a restore before you need one. A backup nobody has restored is a hope, not a plan.

Read the full field note →