Custom software is the first of the four services on our homepage. It is also the one we are most careful about recommending. A request for "an app" can turn out to be a problem that a product the client already pays for could solve, if someone set it up properly. This post is about how we tell the difference, and why saying "do not build this" is part of the job, not a lost sale.
The scene
Our process starts with a step we call Listen: map the actual workflow, find where time leaks and data stalls, and agree on what "done" means. Only after that comes Scope, a fixed plan with a real price.
The reason Listen comes first is that a brief usually names a solution. "We need a CRM." "We need a booking app." "We need a dashboard." Those are product categories, not problems. When we ask what is in the way today, the answer is something like "two people copy orders from email into a spreadsheet every morning." That problem has at least three possible answers:
- Build a system that ingests the orders.
- Configure a platform the client already pays for to do it.
- Connect the two tools they already use so the copying stops.
Only the first one is custom software. It is also the most expensive, the slowest to ship, and the only one that leaves the client owning code that needs maintenance forever. So it has to win on merit, not by default.
Why we sell the alternative too
That is why Implementation sits next to custom software in our service list: third-party platforms deployed, configured, and wired into the systems a client already runs, data included. It exists because "we need software" is often really "we need the software we bought to work."
Our about page puts the studio's rule in one line: understand the job, build the smallest system that does it well, and keep it running. Sometimes the smallest system is a new app. Sometimes it is a settings page nobody has opened since the free trial.
Our own site, as the example
The easiest way to show the rule is our own website, because every decision in it is visible in the repo.
Email: bought. Our contact form and newsletter do not run a mail server. They hand messages to Brevo's SMTP relay through Nodemailer, configured with a handful of environment variables:
SMTP_HOST=smtp-relay.brevo.com
SMTP_PORT=587
SMTP_USER=...
SMTP_PASS=...
Delivering email reliably (reputation, bounces, blocklists) is a full-time discipline, and it is not what anyone hires us for. Renting it costs us some configuration. Building it would cost us a product we would then have to run.
Analytics and fonts: bought. Traffic goes to Google Analytics. Geist Sans and Geist Mono load through next/font. Neither is a place where doing it ourselves would make the site better for a visitor.
The journal: built, but barely. This post is a Markdown file in a folder. One small utility file reads the folder, parse the frontmatter with gray-matter, and render the body with next-mdx-remote. We did not adopt a CMS, and we did not write one. For a team where every writer already works in the repo, a folder of files was the smallest system that does the job.
The spec-sheet design: built. The look of the site is the one part we refused to buy. A template would have made us look like every other studio, and for a studio's website, looking different is the job. That is the line we draw for clients too: build the part that makes you different, buy the rest.
Where custom is the right answer
Grain and Vine is a Coptic Orthodox education platform we designed, built, and still develop: a Sunday School curriculum by grade, Pre-K to 10th, a weekly lesson schedule on the Coptic calendar, daily Synaxarium readings, a companion app, and a dashboard where servants manage the content. The domain is the product there. The calendar, the grade structure, and the way lessons line up with feasts and fasts are the whole point, and a general-purpose course platform would have needed bending at every one of them.
Joel Spolsky made the same argument in In Defense of Not-Invented-Here Syndrome: if something is a core business function, do it yourself, no matter what. The corollary is just as useful. If it is not core, find the best existing tool and spend your effort elsewhere.
Where this breaks
Buying is not free, and our own site shows the costs.
- You inherit someone else's limits. If the email provider has an outage or changes its terms, our form stops delivering and there is nothing in our code to fix. We accepted that trade over running a mail server ourselves.
- The cheap option can be the wrong fit. Our journal works because the people writing it are comfortable with Git. Hand the same setup to a marketing team that wants to publish from a browser, and the "smallest system" becomes a bottleneck. The right answer depends on who uses it, not on what is technically simplest.
- Configuration is still work. Implementation projects fail in the same places custom builds do: data migration, edge cases, and the person who knew how the old system worked leaving. Choosing not to build does not mean choosing not to scope.
And sometimes the test says build, and the client still should not. If nobody will own the system after launch, a custom build slowly turns into an unpatched liability. That is why maintenance is a service on its own line and not an afterthought.
The test
The questions we work through in Listen before anyone writes a line of code. They work just as well before you contact any studio:
WORKAROUND who does this today, how often, how long it takes
SHELF does a product you already pay for do most of it?
CONFIG could that product be set up or connected to close the gap?
DIFFERENCE is the missing part the reason your customers pick you?
OWNER who maintains it after launch, and on what budget?
EXIT if the vendor raises prices or shuts down, what do you lose?
build only if DIFFERENCE is yes and OWNER has a name
The takeaway
Custom software earns its cost when it encodes the thing that makes your business different, and when someone will own it after launch. Everything else should be bought, configured, or connected, even when the studio you are talking to sells builds. If you are not sure which side of the line your problem sits on, send us the WORKAROUND line and we will tell you, including when the answer is a tool you already have.
// sources
// next step
We work this way on client projects too.
Tell us what you are making. We reply with a plan, a timeline, and a price.
