Table of Contents
Do not index
Hide CTA
Hide cover
If you worked for a particularly cutting-edge company in 1997, your first weeks after the holidays would have been spent setting up Microsoft’s new Office ’97 Professional. It promised “hundreds of innovations to enhance productivity.” It came, instead, on 55 floppies that required hours to install, and rewarded you with Clippy, who’d cheerfully guess that “It looks like you’re trying to write a letter,” then offer and often fail to assist with the task.
Installing software from shrink-wrapped boxes was a significant investment in time and money in the ’90s. But at least you were done. You’d never get the hour of installation and reboots back, but it’d mostly be smooth sailing afterwards. Setup stopped at installation.
Not so much with modern SaaS. Signing up for Salesforce is easy; settling in could take a lifetime, always one improvement away from perfection. Salesforce and similar apps are designed for the generic business. But every business is unique, with its own processes, terminology, and approval flows. Hours of installation are replaced with days or weeks of customizing fields, building automated workflows, and training your team. All to make the most out of the software’s limited approximation of your workflows.
Suddenly, inserting 55 floppies doesn’t sound so bad.
As similar customization has crept into more of our work software and, simultaneously, as AI-powered tools have slashed the time and investment required to build custom software, it’s time to reconsider. Whenever you need to buy software today, it’s worth asking: Should you buy software, or should you build something new instead?
Why most teams don’t build their own software
When your team needs new software, a CRM or customer support app, say, the default choice isn’t to buy or build. It’s to buy. The only question is which product to buy.
You survey the market, determine the average price for that category, then try to decide which software can actually do the job at a price that fits your budget.
Building software rarely enters the conversation at all. Software development has always been a slow, arduous process, requiring teams of developers, months of building, and an eternal backlog of feature requests. Building in-house software typically was the domain of large enterprises; everyone else made do with generic off-the-shelf software, customized just enough to solve their needs.
Custom software has always had its allure, though. Like a tailored suit or a bespoke kitchen, a tool crafted for your needs should fit like a glove. A generic invoicing app might include multiple payment and currency options, recurring billing, and perhaps built-in accounting tools, when a custom-built invoicing app for a kitchen builder instead could include milestone-centered payments and a detailed breakdown of the customer’s choice of countertop and hardware.
No wonder, then, that Basecamp grew out of the 37signals team’s work managing website design projects for clients, that Mailchimp started as a tool for The Rocket Science Group to send email newsletters for clients. When tech teams have problems, they’re most likely to build a tool to scratch their itch, then potentially sell it as a new product alongside their original offerings.
But your average carpentry shop doesn’t have a developer on staff, and outsourced custom development makes a custom suit seem cheap by comparison. Even for tech companies, the cost in time and focus is often not worth the added benefits of something custom. You price out building something custom, then quickly decide you’re better off settling for a good-enough pre-made app.
When buying software is better than building
That argument still holds for many categories of software.
You should not design a new Photoshop for your photo studio. A new AutoCAD for your architecture firm. A new Xcode or Visual Studio Code for your development team. A new Avid for a recording studio.
Rare indeed is the firm that would go to that much trouble. These tools codify decades of domain knowledge. It’d require a herculean effort reserved for the likes of Pixar (with their in-house Renderman software to render lifelike animations) to replicate that. And even Pixar uses off-the-shelf, industry-standard software like Maya for core creative tasks.
Creation software—think Google Docs, Photoshop, AutoCAD, Blender, Visual Studio Code, tools where you create documents or images or code from scratch—is still single-player by default. You fire them up and get to work, and after a few hours of focused work, you surface, step back, and share your work. You customize the tools, rearranging toolbars and tweaking shortcuts to fit your personal workflow, but by and large you depend on their core workflows. If you borrowed a colleague’s laptop and opened an Illustrator file in their copy of Illustrator, say, you’d be able to get your work done in short order. Here, software works much as it did in the ’90s, and SaaS merely turned a one-time purchase into a lease.
This is where buying software makes the most sense.
Buy software when it is used for creation, when it’s part of an ecosystem where everyone with your job title uses the same software. Buy when customization is mere personalization, and the software’s core features are too complex to replicate on your own. Buy when building a custom solution is prohibitively difficult or expensive, and when you’re not modeling business logic into the app.
When building is better than buying
The equation changes, though, when there are a wide range of similar, interchangeable tools; when the software is typically used to enter, store, and retrieve data; and, most importantly, when customization is such a large part of the setup process that it takes days or weeks to complete, and may require paid assistance from the software vendor.
The setup creep shows up most readily in the team software most commonly referred to with acronyms like CRM, CMS, ERP, LMS, and ATS. Instead of being used to create new designs or documents, these tools manage the data that your business is built on. Projects and tasks, contacts and contracts, inventory and orders, software where each business uses them in unique ways, where the off-the-shelf defaults are never enough.
Signing up for these tools requires only an email address, password, and credit card. Setup, however, can expand to fill the lifespan of the software.
Customization is most crucial in this type of software, to fit each team’s unique processes around managing tasks, people, inventory, finances, and more. These tools all revolve around capturing your data, organizing it, and turning it into action through dashboards and automations. They’re designed generically enough to work for any company’s projects, contacts, and inventory, with just enough customization options so you can tweak their software into something approximating your company’s workflows.
Countless hours can disappear into tweaking apps to fit your needs. “The worst choice you can make is ‘buy and then build’,” explained one developer about a client who bought Salesforce then customized every part of it. “You spend more than you would have with the build option.” Worse, in cases like this, if the software vendor deeply changes their product, your extensive customizations may break without warning, vaporizing your setup investments.
That’s exactly where building often makes more sense than buying. When you spend more time and effort customizing the app than you spend getting work done in it, it’s time to start considering if building is the better option. Instead of configuration debt, you gain an asset that’s built exactly for your team’s needs, in roughly the same time you’d already spend customizing an off-the-shelf product.
Build software when you need detailed customization, when existing products on the market don’t precisely fit your needs and are priced out of budget. Build CRUD-style apps, where you model your business logic inside the app and the software needs deep integration into your company’s workflows and processes. Build when unique software gives your team a competitive edge.
Building in-house software without developers
Building custom software has typically meant hand-coding it from scratch. Shortcuts existed, from Apple HyperCard and Microsoft Access to spreadsheets, but they were usually stopgap solutions. Purpose-built software still typically offered enough value over simpler solutions and savings over custom development that teams defaulted to buying and customizing off-the-shelf tools.
AI-powered app builders have changed the equation entirely. Developer-focused tools like Claude Code and Cursor now write code alongside developers, while website builders let non-technical users describe what they want then get a working site in minutes.
For the buy-versus-build debate with business software, though, the most meaningful change comes from AI app builders like Zite. These tools let anyone build a CRM, ERP, LMS, and most any other business software they need, without any developer skills. They come with the core software building blocks already in place: A customizable database to store structured data, authentication and permissions to control access, forms to enter data, analysis and visualization tools to make the data useful, and integrations to tie the new software into the broader work software ecosystem. And they use AI to turn your concept into working software, in minutes.
The work in building software in tools like these moves from implementation to ideation. The core security, database, and interface tools are all handled automatically. You’re left to think through your team’s ideal workflow, list the data required for your work and the tasks your team needs to accomplish in the tool, and to communicate that clearly to the AI builder. And in Zite specifically, you can edit the AI-built logic in visual workflows, and tweak the design down to individual elements in a Figma-like editor or tweak the code if you’re so inclined. You’re directing and refining software, more than developing it.
Just like the best custom, in-house software development, the core work is in discovering and building the ideal workflow, one that can fit your needs better than any off-the-shelf tool ever could. “It should be [built by] a small team, led by one person who makes the final call on what ‘perfect’ means,” shared one developer about what’s needed for success when building your own tools. That applies with hand-coded software, and fits equally for AI-directed development with tools like Zite that let anyone build business software.
Instead of endless customizing inside someone else’s platform, you’re investing that effort into crafting a new tool built for your needs. You’ll still spend time customizing and will still have to fight scope creep, just like any other development team would. But this time, each change compounds into a tailored tool that’s ever closer to an ideal fit rather than merely compromises you learn to live with. The result is the same data-centric workflows you’d expect from the alphabet soup of SaaS tools, without the need for either developers or the customization tradeoffs of off-the-shelf software.
Choosing your next new software
Which leaves the decision with you. The next time you need a new tool, do you buy or build?
If it’s software for creation in a market with established industry standards where custom software wouldn’t give you a unique advantage, buy software. You’re in good hands already.
If it’s software where you’ll spend hours customizing the tool for your needs, where the core features are a database and forms, and where a unique tool customized for your needs would give your business a unique advantage, build your software. Not from scratch, painstakingly written line-by-line, but with AI tools like Zite. You trade vendor constraints for workflow flexibility, and in return, every minute you spend customizing compounds into a tool shaped by your work, not someone else’s roadmap.
Image Credits: Header image by Sigmund via Unsplash
Written by
Matthew Guay is a writer and co-founder of Pith and Pip. He previously was founding editor of Capiche and Zapier’s senior writer and editor.
