Q: For this admin backend — an off-the-shelf SaaS, or do you build one?
A: List what needs to be built before picking a solution. We listed 8 items, then made a two-column comparison, marking each "Included", "Needs work", or "Missing".
The Comparison Table
| Feature | Off-the-Shelf SaaS | Custom Build |
| --- | --- | --- |
| Products and inventory | Included | Build it |
| Order list | Included | Build it |
| Role-based permissions | Included | Build it |
| Excel export | Included, fixed format | Build it |
| Operation logs | Included | Build it |
| Message notifications | Included | Build it |
| Daily sync with their existing ERP | Missing, waits on vendor's roadmap | Doable |
| Month-end reconciliation rules | Missing, different logic | Built to your rules |
Six of the eight were already in the SaaS, working out of the box. The remaining two both involved their ERP.
Q: So which did you recommend?
A: Based on that table, I recommended the SaaS. Six items we wouldn't have to build, and the saved time would go into doing the integration properly. The annual fee also worked out cheaper than one development project plus two years of maintenance. I said it straight, no hedging.
Q: What did the client pick in the end?
A: Custom build.
Q: Why? Didn't you try to talk them out of it?
A: We made the case once and let it go. The client's reason was one of those two items: month-end reconciliation. Their rules were worked out with their accountant seven years ago, item by item — which month a return gets charged against, where rounded-off cents land, how one order with multiple invoices keys off the voucher date. All very specific. The SaaS reconciliation logic couldn't be changed, and even if it could, nobody could promise the vendor's next release wouldn't touch it.
"Finance can't wait on someone else's release schedule on the last two days of the month." After that sentence, I had nothing left to say.
What Happened Later
Once the custom build shipped, those six items were honestly rougher than the SaaS — plainer lists, one fixed export format. The client didn't care. What they cared about were items 7 and 8, and those have run steadily for two years, untouched by anyone else's changes.
In a later chat I mentioned that we'd recommended the other option at the time. They laughed and said they knew — they still had our table. It was that table that made them more certain about building custom: the only gap that mattered was those two items; the rest didn't matter at all.
In Plain Terms
When choosing between options, laying out the differences clearly is more useful than handing down a verdict. We gave our verdict anyway — but when the client used that same table to reach the opposite conclusion, with reasons that held up, we went with theirs. A table was never meant to persuade anyone. It's there to make the differences visible.
