Rental software: build or buy? What two custom builds taught us

We have built two rental platforms for one owner: a heavy-equipment rental system in Qatar, and later a vehicle-rental application in Dubai. Both use a Laravel API, MySQL and a Next.js front end. Most of our work is delivered under NDA, so many projects cannot be named. So this page shares what the systems had to do, and leaves out the client’s name and figures.

We don’t sell a rental product. That means no reason to favour one vendor, and an obvious reason to favour building, so check our reasoning rather than taking it on trust.

Don’t count the columns. One strong answer can decide it. If your billing can’t be expressed in the product without a person fixing invoices each month, that alone may justify custom work, while a long list of minor wishes doesn’t.

Use this to brief a vendor, a developer or us. Write your own answer in each row before any demo. If you can’t answer a row, that is worth finding out regardless of what you decide.

Bring a real, awkward contract to the demo, not the vendor’s sample. The hire that was extended twice, changed unit midway and had a disputed damage charge will tell you more than an hour of slides.

On paper, an excavator and a saloon car have little in common. In software, the contract and billing core carried over, and reusing it made the second build faster. The differences sit around that core.

The lesson is practical: if you operate more than one rental line, or expect to, the contract and billing model is the part to get right first. Design it around a generic “thing on hire”, and keep what is specific to each asset in its own modules. Had the first system assumed every contract was an equipment contract, there would have been less to reuse.

More detail on the difficult parts is in rate cards, availability and utilisation and deposits, fines and handover.

Comparing a subscription with a build quote is misleading unless both include everything. Take the same period, five years say, and fill in this list for each option:

• To buy: licences per user or per asset as you grow, setup, data migration, paid integrations, and the staff hours you spend each month working around what it can’t do.
• To build: the build, hosting, security and framework updates, a retained developer for changes, and the risk of depending on few people who know the system.
• Either way: training, moving data, and running the old method alongside the new one for a while.

The workaround hours are often what decides it. Ask the person who raises invoices how long the month-end takes, and what they would stop doing with a system that fitted. Be equally honest about custom software: it isn’t finished at launch. For scale, a dedicated senior developer with us costs ~$5,400 for 160 hours a month, invoiced in USD, GBP, EUR or INR, though most systems need much less than a full-time person once they are stable.

It doesn’t have to be one or the other. A product can run contracts and invoices while a small custom application handles the part that sets you apart: a customer portal, a yard app or a pricing tool. This works when the product has a documented API and lets you export your data. Check both before you rely on them, and find out what the vendor charges for API access.

It fails when the edge needs data the product won’t share in time. If your custom app has to know availability to the minute, and the product only exports overnight, you have two sources of truth. That is the problem you were trying to solve.

Plenty of rental companies run well on spreadsheets or an old system for years. Replacing either costs time and attention, so look for symptoms that are costing you something rather than a general feeling that it should be better.

• Staff phone the yard to find out whether a unit is free, because the screen can’t be relied on.
• Invoices are checked against contracts by hand, and the checking regularly finds errors.
• Extensions and early returns get billed late, or not at all, and customers find the mistakes first.
• Only one person understands the workbook, and everyone worries about what happens when they take a holiday.
• Nobody can say which equipment classes earn their keep without a day of manual work.
• Opening a second branch or a new asset type would mean copying the whole arrangement.

If two or three of these sound familiar, some system change is probably worth pricing. These symptoms don’t tell you whether to buy or build. They tell you what the new system must fix, so turn them into your first test cases.

Vendors’ demos are designed to go smoothly, and that isn’t a criticism. To learn whether a product fits, you have to take over the script. A short, structured trial with two or three shortlisted products will tell you far more than comparing feature lists.

1. Pick five real contracts, including the worst one from last year. Take out anything confidential.
2. Enter them yourselves. Have the people who do this every day try it, not only a manager and a sales engineer.
3. Raise the invoices, and compare them to what you actually billed. Every difference is either a bug in your old process or a gap in the product.
4. Change something mid-hire. Extend, swap a unit and add a damage charge. Note how many of these need a workaround.
5. Pull the report you look at every Monday. If it can’t be produced, ask what it would take, and from whom.
6. Export everything, then read the file. Check line items and history are included, not just headers and totals.

Keep a simple list of each workaround, with who would do it and how often. That list is the honest monthly cost of “it nearly fits”, and it goes straight into the comparison above. If the list is short, buy the product and stop reading articles like this one.

Whichever you choose, data is usually the slowest part, and it is your work rather than the supplier’s. Start before the software decision is final, because the clean-up pays off either way.

• Give every unit one identity. A fleet number or serial that appears the same way everywhere. Duplicates surface fast once you try.
• Clean the customer list. The same company under three spellings will split its statement and its credit limit.
• Agree the opening position. Open contracts, deposits held and unpaid invoices need a date on which someone signs them off.
• Decide what history you really need. Bringing over closed contracts costs effort. A read-only archive may do.

• Who else runs a rate structure like ours on this, and can we speak to them?
• When did you last change a billing rule at a customer’s request, and what did it cost them?
• What happens to our data, and in what format, if we leave?
• Who has access to our customers’ records, and how is that logged?
• How are updates released, and can a change break our customised parts?
• What is not included in this price that most customers end up paying for?

These work on us as well. Good answers are specific and a little uncomfortable, and a supplier who claims nothing has ever gone wrong probably hasn’t been asked properly before.

1. Collect the awkward cases first. Real contracts, real credit notes, real disputes. They are your specification and your tests.
2. Start with the register, availability and contracts. Everything else depends on them.
3. Keep invoices immutable once issued. Corrections should be credit notes, so the books can always be explained.
4. Plan the cutover around open contracts. Decide how a hire that spans the switch is billed before you set a date.
5. Release to one branch or asset class first, and run old and new side by side until the invoices agree.

Our rental sector page describes how we approach this work.