Custom Software Development: Which Part to Build

Custom Software Development for Business: What to Build, What to Keep

Somebody probably said it at the end of a production meeting, or in the truck between two job sites. “We can’t keep going like this with the tools we have.” Ever since, the question has been circulating through your company, from the office to the shop floor, in a form that looks simple. Do we buy a piece of software, or do we commission custom software development?

Custom software depends on one slice of your work, not on your size

A twelve-employee company sometimes carries a slice of work that no software vendor has any reason to build. Custom software serves that slice, the one that exists only at your place.

A commercial software product is written so that thousands of companies get their needs met through a long list of features. Accounting and payroll are two examples. In certain specific cases, it does the job better, and for less, than anything we could build for you; so we leave it alone.

The rest, as in many small and mid-sized businesses, is a layer that has formed around the software. Excel files calculate what the ERP does not know about your machines, and one-off emails stand in for approvals. The manual workarounds and the little tricks for getting the most out of the big popular package are taught to the new hire once the official training is over.

Which operation in your company is not done the way similar companies do it?

Procedures that only one person in your company is responsible for can be automated, or at least made easier to run. And if a procedure ties up several people on the very operation your customers choose you for, you are looking at the part worth rethinking. Custom software development costs you the development fees up front, before you have seen a single screen; a SaaS subscription spreads out month by month. In exchange, the software does what you described and does it more smoothly, with the functions you want, the procedures you choose and plenty of other advantages.

Replace the software, or build what it misses: how we decide

When an existing package covers almost the whole need, we build the piece that is left and plug it in. Replacing comes as a last resort.

That connection runs through an API, the interface through which one piece of software agrees to let another talk to it. Most software rented by subscription offers one. Two questions apply to it: does it exist, and do the API permissions allow writing as well as reading?

Take customer-specific price lists. At your company they may live as dated attachments in the sales reps’ inboxes; the invoicing software is not the problem. Agreements that depend on the year’s volume are a rule of your own. We program it into a small module that calculates the price and writes it into the invoice through the API. The trade-off: that piece depends on the vendor’s API, and the vendor keeps evolving its product and may or may not allow additional third-party access.

When the layer built around the software outgrows the software itself, replacement moves to the front. If the office plans the week’s deliveries in a paper day planner and only opens the software to invoice, the real system is the day planner. And if the software being outgrown is itself an in-house program, the question becomes one of modernization, which follows a different line of reasoning.

What would be lost if your current software disappeared tomorrow morning? As a rule, if the answer fits in two lines, replace it. If it takes a page, complete it.

Seven signs that hours are being lost alongside your software

Several signs point to a current solution that needs rethinking. Here are a few examples:

• The planning spreadsheet gets reprinted at the start of the week because the real running order on the machines was never entered in the ERP.

• Estimators pull their quote numbers from a shared notebook so that two people do not issue the same number on the same day.

• The “comments” column in the CRM doubles as the status of every file, in abbreviations somebody has to explain to you.

• The office calls the foremen back on Thursday to find out who was on which job site, because travel hours are not written down anywhere.

• The invoice only goes out when the driver brings the delivery slip back to the office, sometimes two days later.

• Technicians on the road phone the office to find out whether a part is in stock, because inventory can only be read at the counter.

• A reminder in the operations manager’s calendar is what triggers a manual check on the parts whose reorder threshold shifts with the season.

• Two of these signs justify counting the hours. At five or more, it is a clear sign that your software needs to be rebuilt.

• One of these signs can also mean that a feature of your current software is sitting unused, or that employee training stopped too early. We check that before proposing anything, because it costs less than we do.

What drives the price up, in the order we look at it

Over the phone, we do not give a price without a full diagnostic. We look at the scale of the work, the various factors to weigh, the level of integration to plan for, the languages needed to talk to the rest of your software ecosystem that has to communicate, and plenty of other factors.

First, the number of systems to connect. A system integration gets programmed twice: once for the normal case, and once for the cases where there is a partial or complete outage. When the accounting system stops responding for an hour, orders have to wait in a queue and then go through on their own afterwards, with no duplicates. That work never shows up in the mockup, and it weighs on the price.

Next, the exceptions. A purchase approval rule with two exceptions means three paths to program and to test. An exception that comes up three times a year can stay manual. Then the data to carry over: if your price history has changed format over the years, we decide with you what gets kept. Finally, who tests? Depending on the case, we can put dummy data into testing, or a sample of your real data.

Two things bring the price down: a clearly bounded need, and current software with a documented API.

Custom software development is paid first in your people’s hours

During the project, the timesheet that grows is your internal tester’s, and it counts as much as our invoice. That tester fields the developer’s questions, such as why does quote number 4 carry two labour rates? They try out one delivery before the developer starts the next, and they make the call when a rule turns out to have more exceptions than expected.

Without that person, the developer assumes things with no real validation. The assumption gets corrected later, and the correction costs more than the answer would have. Depending on the mandate, budget a few hours a week for this person during development, then full days for testing the first delivery.

The best-placed person is often the one with the least time: the operations manager, or the foreman who knows the machines. Who on your team can answer a developer’s question the same day without production suffering for it?

After delivery, someone at your company becomes the go-to person for taking stock of the functions still to add, whether for exceptions nobody had thought of or for features that would improve efficiency and were never considered or requested.

Strategic development through MVP and POC

We do not build the whole piece of software before showing it to you. We cut the mandate into slices, and the first one contains a single task: the one where the hours are going.

Before we start, a proof of concept (POC), a throwaway build that verifies one technical point, answers the question that scares everyone. Will your ERP let us write into it, with your real data, without breaking invoicing? That build is billable, and it is part of our overall proposal. In exchange, you know whether the connection holds before you commit to the rest.

The second version then arrives in usable form, and we ask your tester to have it tried out, that same week, by the employees who do the task. Deliveries come with their automated tests, programs that replay the known cases every time the code changes. When a rule changes, the test for the previous rule raises the flag before your employees do, for the cases it knows about.

What the agreement has to put in writing about the code and your data

The source code comes back to you, under the terms of our contract, in a repository in your name: the online space where it is stored and tracked.

Owning the code is not enough to take it over. For another team to pick it up one day, four things have to exist.

A language developers commonly work in. Documentation that says how to install the software on a new server or computer. Access to the hosting and to the repository. A readable change history, which Git produces on its own.

Where the software runs is a decision, not a detail. On a server at your place, or in the cloud, meaning on rented servers in a data centre, often in Canada.

Hosting outside Quebec is still allowed. Before you do it, Law 25 requires a privacy impact assessment as soon as personal information is involved. If that is your situation, we will design with those obligations in mind: who accesses what, and where the backup copies sit. Beyond that, your privacy officer or the Commission d’accès à l’information (CAI) are the right people to talk to.

Then there is maintenance. With a plan arranged either at the initial signing or later on, the software vendor applies the security patches. With software of your own, somebody has to apply them, because libraries, those third-party pieces of code yours depends on, receive them all year long. It is a recurring expense, with us or with another firm, and it is part of the real price of going custom. Ask whoever you are talking to what happens if a library changes and the software stops starting up on a Monday.

What we need in order to quote your custom software properly

You should be asking yourself the following questions:

• What do you recommend I keep from my current tools? A useful answer names specific functions and says why.

• What part of my project will cost more than I think? Expect to hear the name of a specific integration or a specific exception.

Book a meeting to talk about your project

We would be glad to take part in the success of your custom software project, and we are offering a 30 to 60 minute meeting to discuss it with no obligation. Request your meeting or your quote through our contact form.