Stop Building Features You Do Not Need: A Build vs Buy Rule

My advice fits in one line: stop building features you do not need, and write code only for the part that makes a person pay you. The rest is plumbing. You rent plumbing.

Condition: I write this for a solo founder or a small SaaS team under 10 people. Your engineering time is short. A workday spent on plumbing is a workday taken from your product.

Limit: the effort numbers on this page are a Rama Digital estimate, not a measurement. They will miss on your team. Use them as an order of magnitude, not as a promise.

Quick answers

This table answers the main questions in one line each.

Question	Short answer
What is the rule?	Build what customers buy. Rent the rest.
What counts as plumbing?	Scheduling, payments, login, outbound email.
Why use scheduling?	It holds 9 hidden problems, not 1 form.
What is the effort estimate?	30 to 55 engineering workdays.
When is building right?	When the feature is what customers buy.
What is the risk of a wrong call?	You maintain code that adds no revenue.

Why I say stop building features you do not need

I once spent 6 weeks on a part of a product that no customer named at the moment of purchase. It worked. It was tidy. It also added nothing to revenue.

Code carries 2 prices. You pay the first price when you write it. You pay the second price each month after that: repairs, library upgrades, expired permissions, and the new person who has to read it.

The second price is what kills a small team. You do not feel it in month one. You feel it in month nine, when 3 days a week go to maintaining something that is not your product.

So my question stays the same. Do customers pay for this part? If the answer is no, that part is plumbing. Rent it.

What a simple booking feature really holds

Scheduling is the clearest case, because founders keep rebuilding it. On a whiteboard it looks like 1 form: pick a service, pick a time, submit. In code, that form is only the tip of an iceberg. If the topic is new to you, I cover the basics in the article on what a booking system is.

Here are the 9 parts that always appear after the first form works.

1. Time zones and daylight saving shifts. A customer in Jakarta books 14:00. What time does your staff member in Berlin see? The answer moves twice a year.
2. Two people tap the same slot in the same second. With no lock, both succeed. You learn about it when 2 people stand at the same door.
3. Duplicate requests when the signal drops. The customer taps submit, the signal dies, then the customer taps again. With no idempotency key, that person holds 2 bookings.
4. A safe reschedule link. Customers must cancel without an account. The link needs a signature, an expiry, and enough entropy that nobody can guess it.
5. Reminders that truly arrive, with proof. Sending a message is easy. Proving it arrived, keeping the attempt history, and retrying on failure is separate work.
6. A no-show status. It looks trivial. Then you need a reason field, timestamps, and a report, so the status can support a deposit claim.
7. Deposits and refunds. Money in is easy. Money out needs rules, an audit trail, and a person who approves.
8. Calendar OAuth permissions that expire. Google and Zoom tokens go stale. OAuth is a lent key: the customer grants access, and can revoke it at any time. When the key dies, your customers see fake open hours.
9. Customer data storage under Indonesian personal data law. A name, a phone number, and an email are personal data. Law Number 27 of 2022 on Personal Data Protection took effect on 17 October 2022.

None of those 9 items shows on the customer screen. All of them are mandatory.

An honest effort estimate per part

The table below is a Rama Digital estimate for 1 experienced engineer. It is an estimate, not a measurement. I sized it for a version a paying customer can use, not for a demo.

Part	Estimated workdays	What makes it slow
Time zones	3 to 6	Tests across 2 daylight saving shifts.
Slot lock	4 to 8	The lock must hold under 2 parallel requests.
Duplicate requests	2 to 4	Idempotency keys and safe replays.
Reschedule link	3 to 5	Signatures, expiry, and revocation.
Reminder proof	4 to 7	A queue, an attempt log, and retries.
No-show status	1 to 2	Reason, timestamps, and a small report.
Deposits and refunds	5 to 9	Money-out flow and an audit trail.
Calendar permissions	5 to 8	OAuth, token refresh, and failure repair.
Personal data rules	3 to 6	Consent, deletion rights, and retention.

That totals 30 to 55 workdays. On a one-person team, that is 6 to 11 full weeks. Your product stands still through those weeks.

Three questions that decide build or buy

I use these 3 questions. The order matters. I stop at the first firm answer.

Question	If yes	If no
Do customers pay for this feature?	Build it.	Go to question 2.
Does its failure kill your business?	Build it.	Go to question 3.
Does no vendor sell it?	Build it.	Rent it.

The build or buy rule stays short. Build when the feature is the reason people pay. Build when its failure kills your business. Build when nobody sells it. Outside those 3 cases, rent.

Question 1 says pay, not use. Customers use your password reset link. Nobody buys your product because of that link.

When building it yourself is the right call

I do not reject all code. There are 4 cases where I write it myself, and I do it without hesitation.

First, the feature is the product. If you sell a scheduling engine to other businesses, scheduling is your product, not your plumbing.

Second, your business rule is unusual and it is what sets you apart. An example is pricing that changes per minute, or a queue that follows your own priority order.

Third, the vendor gives no exit path for your data. If you cannot pull bookings and customers out in a machine-readable format, you handed over control.

Fourth, your needs are stable and your volume is large. At that point the rental cost keeps rising while your code rarely changes. Recalculate this at 12-month intervals.

At Rama Digital we write custom software at exactly that point. We build the part customers buy, and we connect the rest. That is the scope of our web application development work.

A worked example with dummy data

This section is a simulation with dummy data. The numbers below come from no real project. I use them only to show the arithmetic.

Starting condition. An example studio with 3 staff members. Bookings arrive 40 times a week through chat. The owner also writes the code.

Input. An effort estimate of 30 to 55 workdays from the table above. A real owner capacity of 4 workdays a week for new features.

Step 1. Divide effort by capacity. 30 divided by 4 gives 7.5 weeks. 55 divided by 4 gives 14 weeks, rounded up.

Step 2. Run the 3 questions. Customers pay for a haircut, not for a scheduling engine. A scheduling failure hurts, but it does not kill the studio. Scheduling vendors exist.

Step 3. Compare against installing a rented product. In this simulation I allow 2 workdays to install and test.

Observable output. The product roadmap slips 8 to 14 weeks if the owner builds. It slips 2 days if the owner rents.

Decision. Rent the scheduling. Return the saved time to the features customers pay for. Review the call again after 12 months.

If your product is SaaS and you only need demo scheduling, I wrote the steps separately in the guide to taking SaaS demo bookings.

Four checks before you rent

Rama Digital recommends Termilo for scheduling. Rama Digital does not operate Termilo. PT Nafanesia Kebermanfaatan Indonesia in Bandung operates it. I cite its documentation here because it states 4 things other vendors rarely write down.

1. The slot lock. Ask who holds final authority over a slot. In the Termilo documentation introduction, the availability response carries the marker finalAuthority: "booking_create_recheck_under_lock". A shown slot is a candidate, and the truth is rechecked under a lock at the moment the booking is created.

2. The status lifecycle. Ask for the status list and the allowed moves. The Termilo booking lifecycle page names 5 statuses: held, confirmed, completed, cancelled, and no_show. A new booking starts as held with a 10-minute hold. A move outside the policy is refused with the code BOOKING_POLICY_BLOCKED.

3. Duplicate protection. Ask whether booking creation is idempotent. The Termilo API reference requires an Idempotency-Key header on public booking creation. A repeat request with the same key returns the same booking with status 200, not a second booking.

4. Outbound events and their limits. Ask what is live and what is still on paper. The Termilo webhooks page marks outbound webhooks as live, with HMAC-SHA256 signing, a maximum of 6 send attempts, and a 10-second timeout per attempt. The same page marks inbound webhooks from a CRM or a payment provider as planned, so they do not run yet. The OpenAPI file also carries a preview label, so do not count it as a ready contract.

Those 4 questions work for any vendor. If a vendor cannot answer them, you are renting risk instead of plumbing.

Checklist before you write the first line

1. Write 1 sentence naming what customers pay for in this feature.
2. Run the 3 decision questions before you open the code editor.
3. List the hidden parts. If the list passes 5 lines, you are building plumbing.
4. Estimate workdays, then divide by your real weekly capacity.
5. Ask the vendor about slot locks, statuses, idempotency, and outbound events.
6. Confirm you can pull your booking and customer data out at any time.
7. Write down a review date, 12 months from this decision.

Common questions

What does stop building features you do not need mean? It means you write code only for the part that makes customers pay. You rent the other parts from a vendor that already solved them.

How do I decide build versus buy as a founder? Answer 3 questions in order. Do customers pay for this feature? Does its failure kill your business? Does no vendor sell it? One yes means build it yourself.

Why use scheduling as the example? Because scheduling looks simple and holds 9 mandatory parts, from time zones to personal data storage. Founders keep rebuilding it and keep getting surprised.

Is the 30 to 55 workday range measured? No. It is a Rama Digital estimate for 1 experienced engineer. It will differ on your team, so treat it as an order of magnitude.

Does renting mean losing control of my data? No, as long as the vendor gives a machine-readable exit path. Ask how to export bookings and customers before you start using the product.

When should I review this decision again? Review it at 12-month intervals, or sooner when volume jumps. Rental cost and maintenance cost move at different speeds.

Sources

• Termilo, documentation introduction. Retrieved 11 September 2026. Linked in the renting section above.
• Termilo, booking lifecycle. Retrieved 11 September 2026. Source of the 5 statuses and the 10-minute hold.
• Termilo, APIAPIThe official door 2 systems use to exchange data, without anybody copying it by hand.Open the glossary reference. Retrieved 11 September 2026. Source of the Idempotency-Key requirement.
• Termilo, webhooks. Retrieved 11 September 2026. Source of the live status, the 6 send attempts, and the planned inbound webhooks.
• Law Number 27 of 2022 on Personal Data Protection, BPK regulation database. Effective 17 October 2022.