Build vs buy software: two decisions from one small team, with opposite answers
We bought notification delivery and built our own translation review. One small team, opposite answers, and the rule that decided both.
Published 5 min readFurther reading
In this article6 sections
My team paid Transifex $150 a month to get English strings translated into Arabic. I replaced it with a workflow I started on a Saturday as a side project. Earlier the same year, I threw away two days of my own notification design and made the call to buy a service instead.
Both decisions came from the same four-developer team at a property-management startup, and I'd make both again. The reasons they went opposite ways are more useful than either answer.
Decision one: we bought notification delivery#
Landlords needed a notification centre. They wanted to know when a settlement was transferred, when a maintenance request came in and when a lease was about to expire.
Our API ran on Cloud Run, Google's serverless platform, where long-lived WebSocket connections are awkward to manage. A landlord didn't need a settlement notice within a second; five to ten seconds was fine. So I designed a polling system: a queue for new notifications, PostgreSQL as the record, a Redis cache that expired after 24 hours, a cursor so each browser fetched only what it hadn't seen, and fallbacks for missed messages and sleeping tabs. It took two days to design and I could defend every part of it.
Then, in a weekly meeting, our CEO mentioned that a mobile app would launch in a few months. Mobile meant push notifications. Email was coming too. Every new channel would be another integration that I would build, own and debug for as long as the product existed. The brief had described a web feature. The product needed a delivery platform.
I scrapped the two days of work and wrote down what a vendor had to offer:
- A React Native SDK with a ready-made inbox, so we wouldn't build notification screens on mobile.
- Translation support on every plan, because our users read Arabic and that couldn't be an enterprise upsell.
- One API call that reaches web, mobile and email.
One option made us build the mobile interface ourselves. Another kept translations behind an enterprise tier. Courier met all three. It had one gap for us: no Angular SDK, so I mounted its web component directly in our Angular app.
What we kept was the part only we could write. Our service decides who receives each notification: specific people, everyone with access to a given lease or settlement under our existing permission rules, or every active member of an account. It checks preferences, saves the notification, queues the send and stores Courier's request ID for tracing. Courier only delivers.
The cost is a dependency. If Courier is down, notifications stop. For four developers, owning delivery across three channels was a worse risk.
Decision two: we built translation review#
The product ships in English and Arabic. The engineers write English and can't verify Arabic, so every Arabic string went through this loop:
- AddA developer adds an English string.
- QueueIt appears on the Transifex dashboard.
- TranslateAn Arabic-speaking colleague on the business side translates it.
- Pull requestThe Transifex bot opens a pull request with the translation.
- ShipThe Arabic version ships.
The $150 a month bought a human checkpoint that worked well. The waiting was the real cost.
We never fixed it earlier because building our own meant writing parsers for translation files and their placeholders, and we would still need a person to translate. Owning it cost more than renting it.
AI changed that arithmetic. An agent can read the translation file, open the source code to learn what each placeholder means, and draft Kuwaiti Arabic. The first version kept dropping or misplacing placeholders, so I added a validation script that fails if any value from the English string is missing, added or changed. The agent isn't done when it says it's done. It's done when the script passes.
The human checkpoint stayed. A small reviewer portal shows English next to the agent's Arabic, grouped by section, and commits fixes back to the repository through GitHub's API. A separate ledger stores the exact Arabic each reviewer approved, with their name and the time. The portal compares live text against that ledger, so when the agent rewrites a string, it drops back into the review queue without anyone flagging it.
When I wrote this up in July, the result looked like this:
| Measure | Before, with Transifex | After |
|---|---|---|
| Time for a new string to ship in Arabic | 3 to 4 days | Hours |
| Monthly tool cost | $150 | $0, hosted on Vercel's free tier |
The same review screen now covers six app surfaces across two repositories and three file formats. The $150 we stopped paying now covers about three-quarters of the Claude Code subscription the agent runs on. These are my own reported figures from that period, not audited savings.
The rule behind both decisions#
Delivering a notification is the same problem for every company, and vendors solve it at a scale we never would. Deciding who should hear about a lease depends on our permission model, and no vendor knows it.
The translation workflow stayed small in the dimension that matters: two languages, one dialect, one product domain and a handful of people. When a problem fits in one person's head, owning it is cheap.
Here is how I'd use that rule on your next decision:
| Question | Points to buying | Points to building |
|---|---|---|
| Does every company need this to work the same way? | Yes, like email, push or payment processing | No, like your permissions, pricing or approvals |
| Will the scope grow in ways you can't see yet? | New channels, markets or languages are coming | The scope is fixed and small |
| What does a year of ownership cost? | More than the subscription | Less than the subscription |
| Can AI draft most of it, with a strict check you control? | No | Yes |
When I'd still pay#
I'd keep paying for translation if we supported thirty languages, because then we'd be running a localisation company by accident. I'd keep paying for legal or medical copy, where a bad translation is a liability and you want a vendor with a proven process. And I'd keep paying if a real localisation team lived in that tool every day, because taking it away would make their work worse to save a subscription.
The question I'd ask first now#
The notification design failed because I never asked one question in the first meeting: where else will this need to go? Ask it before you design anything, and price a year of owning the result as well as the week of building it. Then check whether the vendor supports your actual stack, as Courier's missing Angular SDK reminded me.
The AI side of this story, including the checks that made the agent's work shippable, is in does AI speed up software development?
At The Useful Company, Saumya and I hold to a simple rule: if a smaller tool or a subscription solves the problem, we say so. If you're weighing a tool you rent against something you could own, send us what it costs and what annoys you about it. We'll tell you which side we'd pick, including when the answer is to keep paying.
Further reading#
Both stories first appeared on DEV, written for engineers: the notification system design and the translation workflow.