All notes
Behind the website3 min read

When a bit of custom code makes business easier.

Coding sounds like something that happens behind a website. Sometimes the most useful bit is a small tool that saves you doing the same awkward job over and over. You do not need to arrive with a technical specification to talk about it.

Illustration of a developer’s laptop and notebook on a coastal workbench

Describe the repeated job

Perhaps you copy every enquiry into a spreadsheet, retype the same information into two systems, or work out a rough estimate with a calculation only you understand. Start there.

Write down what arrives, what you do with it and what needs to come out at the other end. Include the exceptions. A process that looks simple until somebody changes a date is worth understanding before anyone starts building.

A useful form can do more of the preparation

A tailored form might ask different questions depending on the service, collect the details needed for a quote or turn a complicated request into a tidy summary. It should make the customer's job easier as well as yours.

An estimate tool can be useful where the rules are clear. It also needs to explain what the estimate means and when a proper quote is still needed. If the price depends on seeing the work, the website should say that plainly.

Connect tools where there is a sensible route

Some services provide an API, which is a way for software to exchange information. Where the tools support it, a small integration can move agreed information between them without somebody retyping it.

That still needs decisions: which information moves, who can access it and what happens when a service is unavailable. Check the existing software's features first. An option already included in a tool you pay for may solve the problem without custom development.

Build a small version you can try

A first version should prove the useful bit. One form, one calculation or one repeated task is easier to test than an ambitious system that tries to run the whole business.

Try ordinary examples and awkward ones. Does it handle missing information? Can you correct a mistake? Does the result make sense to somebody who did not build it? Time spent on those questions is part of making the tool dependable.

Someone needs to look after it

A custom tool can depend on services, accounts and software that change. Agree what it relies on, what it costs to run and how fixes or future changes would be handled.

Keep access, documentation and a way to recover the work in the conversation from the start. A shortcut that only one person understands can become another problem to manage.

What I can help with

I'm a software developer as well as a web designer. I can help look at the process, check whether an existing tool fits, and scope a small custom feature or integration where that would be useful.

Custom software is quoted for its requirements; it is not automatically part of a website package. Tell me about the repetitive or awkward bit of your work. You can explain it in ordinary business terms. Working out the technical route is my part.

Stephen Murdoch

Written by Stephen Murdoch.

Web designer and developer in Largs. If you've got a question about your own business, I'm happy to help.

Fancy a chat?