Skip to main content

skaal / resources

build vs buy: when custom software makes sense

How to decide whether to keep configuring an existing product, customize what you already have, or build an owned tool — including cost of ownership and integration.

Introduction

Most software decisions are not “innovate or fall behind.” They are “keep paying for this, reshape it, or own something that matches how we actually work.” Custom software is appropriate in some of those cases. It is the wrong answer in many others. This guide is a way to decide without pretending every business needs a platform of its own.

What existing software is already good at

Off-the-shelf products exist because many companies share a workflow: invoicing, email, payroll, commodity file storage. If the product does the job, the team uses it, and the cost is in line with the value, buying is usually the cheaper path — including the cost of not having to maintain the tool.

The failure mode is not “we use a vendor.” The failure mode is paying, month after month, for a platform whose unused majority is the actual product.

When customization of an existing product is enough

If the gap is a report, a field, a permission, or a modest integration, configuration is usually enough. Customization still has a cost: upgrades get harder, and you inherit the vendor’s roadmap.

Ask whether you are stretching the product because it is almost right, or because nobody has admitted it was the wrong category of tool.

When an owned solution may be appropriate

An owned tool may be the better fit when the workflow is specific, the subscription is seat-limited and barely used, or control of the data and the roadmap matters more than renting a generic feature list.

Skaal uses Vibe Coding to help businesses explore and build custom software solutions: replace a bloated, underused subscription with a tool you own and actually use. Cadence replaced spreadsheets, shared drives, and approval threads for content operations. Skaal Expenses System replaced a recurring expense-reporting subscription for Skaal’s own operations. Those are examples of the pattern — not a claim that every subscription should be rewritten.

  • The team uses a small slice of a large product and pays as if it used all of it
  • The work starts in a way generic CRMs and trackers do not model
  • You need the system to remain yours if the vendor changes terms
  • Integration and records have to match how this business already runs

Total ownership considerations

Buying has a visible invoice. Building has a less visible bill: design, implementation, hosting, backups, access control, and someone who understands the tool next year.

Ownership is still often cheaper than a seat-limited subscription that will never fit — but only if the business will actually use and keep the tool. An owned system that nobody maintains becomes another kind of unused software.

When you take on a Skaal product, the platform is deployed for your business and yours to keep. Ongoing evolution with Skaal is a separate engagement. That split is intentional: ownership should not secretly be a retainer.

Integration requirements

A new tool that cannot talk to the systems around it will be bypassed. Before you build, map what must flow in and out: identities, files, approvals, money, customer records.

If those edges are undefined, you do not yet have a build-vs-buy decision. You have a systems-mapping problem. See the companion guide on connecting disconnected business systems.

Long-term maintenance

Decide who will own the tool after the first version is in production: an internal person, Skaal under a separate engagement, or a combination. If the answer is “we will see,” you are not ready to build.

Prefer a smaller system that matches the real workflow over a platform that anticipates every future request. Unused flexibility is how custom software becomes the next bloated subscription — only this time you are the vendor.

  • Vibe CodingReplace a bloated, underused SaaS subscription with a tool you own and actually use
  • MSP / IT SupportKeep the business running without drowning in operational firefighting

questions

When might Vibe Coding be relevant?

When the business is paying for a subscription it barely uses, the workflow is specific enough that configuration will never fit, or ownership and long-term control matter more than renting a generic platform. Existing software is often the right answer. Vibe Coding can be used to build software around specific business workflows — not a claim that every company should replace SaaS.

Vibe Coding

Can Skaal help with internal business tools?

Yes, when that is the problem. Vibe Coding includes owned tools for internal operations. Skaal built Skaal Expenses System for its own expense reporting, and Cadence for its own content operations. Those products can also be deployed for a business to keep. Other internal tools are scoped from the actual workflow, not from a catalogue of every possible app.

Products

If we use a Skaal product, who owns it?

When you bring on a Skaal product, you get what has been built — deployed for your business and yours to keep. You can customize, adjust, and extend it. If you want Skaal to keep evolving it with you, that is a separate, ongoing engagement. Pricing is discussed through Contact, not listed as public figures.

Products

If this problem is live in your business, start with a conversation — not a packaged pitch.