Cutting the Budget Without Cutting Corners: Building Custom Software for Less

For a new application, budget concerns come in a number of flavors:

• It’s too early to raise funds or terms aren’t favorable
• A few benchmarks need to be hit before the “rest” of the budget is released
• There’s competition for the money, like other projects or economic concerns

Cost-cutting measures come in their own array of flavors, too. Making due is a matter of making the right cuts — changes that don’t sacrifice quality or guarantee future headaches. We’re looking to introduce “good” problems by delaying some work until it coincides with runaway success. The “oh no, we have too many customers” kinds of issues, not the all-too-common “oh no, everything’s on fire and we can’t tell why” ones.

Let’s take a look at the safer long-term ways to save on software.

Build Fewer Features

Just remove some stuff. Brilliant, right? Novel insight.

It’s no secret that stripping some complexity out of an application will decrease the cost, but it’s still the ideal place to start. Fewer things to build, fewer things to test, and fewer potential side effects. Having a bunch of half-baked, buggy features that users rely on is a surefire way to stunt a product’s growth.

A tighter definition of minimum viable product is popular for founders the second time around, but you have the inside track to try it now.

Keep the “How” Flexible for Third-Party Libraries

The custom part of custom software means that everything can work exactly how you dreamed it up. If you’re a little flexible on those details, though, there are plenty of ways to save.

Take a long list of to-dos, for example. Your heart may be set on an interface that scrolls infinitely, but pagination is a quicker solution with fewer side effects. The effect on end users is minimal (and may even be a net positive, ethically), and the implementation savings are significant enough to take seriously in a crunch. Further, there’s a clear path for future iteration.

Off-the-shelf libraries may not grill a steak to your exact temperature preference, but, at least as far as v1 is concerned, it’s still steak. If you’re trading a few minor process details for a bunch of “free” open source features, you’re getting a good deal. It’s a key part of the build versus buy debate, and price may just be the tipping point.

Deal With Complexity Manually — For Now

You want to automate the tedious stuff, and so do I. Manually tackling a couple features, though, is the easiest way to slash a budget. Examples I’ve seen include:

• Creating and inviting users by hand, rather than through a self-service sign up
• Invoicing subscriptions outside of the application
• Asking the development team to make occasional copy tweaks, instead of adding a full-fledged content management system
• Regularly uploading a spreadsheet of data, as opposed to a series of API integrations and automated data cleanup

Each can save days or even weeks of effort in the short term. As each hits a threshold where you can’t keep up, you’re firmly in “good problem” territory. At that point, automation has already proved its need and value ahead of implementation.

Identify Which Features Depend on Volume

Keep an eye on features tied to volume, too. New users start with a blank slate, and some data takes time to accumulate.

If you provide a media library, what’s the average pace of new uploads? If it’s two per week, there’s room to maneuver before pagination, searching, and filtering are really useful. Performance issues typically won’t rear their head yet, either.

If it’s two uploads per hour, then yeah, they’ll be a problem too soon to put off.

Aggressively Cut Integrations

What if we add the local weather? And pull a few recent social media posts? Integrating outside data sounds pretty simple, and can be — especially if it’s not mission critical. On the flip side, it’s easy for the important stuff to take upwards of a week (each), since a developer needs to:

• Spend some time with the documentation
• Write the actual integration
• Add appropriate tests
• Smooth over any data inconsistencies between sources
• Adjust for downtime and fallbacks

We’ll use third-party CRMs as our example here. Wanting to integrate with your customers’ CRMs from day one makes a lot of sense, but supporting every major CRM out there is a big ask. Do most of the folks in your beta use Salesforce? That’s a great place to start. It’s more important to set a smooth process up for adding new integrations than hammering them all in there haphazardly.

As with features in general, be quick to cut non-vital sources of data.

Have Design Join the Money-Saving Fun

I’m an experience-first sort of person, so this one hurts my heart a bit: Saving is a team exercise, and design is part of that team. Creatives have a pair of questions to chew on:

• How much value does a unique design really add, for now? Leaning on an off-the-shelf UI kit — even if it costs some money — is a great way to get a head start on front-end components, too.
• Will the user even see this? While administrative tools shouldn’t be cumbersome or inaccessible, they can stand to be uglier than the customer-facing interface.

Design is a forever problem, but forever will still be there tomorrow. Ideas on the grander, creative part of the scale can wait until the product has found its feet.

Pay More for Hosting

Paying more for server space may sound counterintuitive, but bear with me here.

Configuring the perfect way to deploy, monitor, stage, and serve code takes time, is a moving target, and generally needs someone with a devops background. If the team lacks that specialization or the funds to craft the right solution, you can turn to managed services or cloud providers that simplify the nitty-gritty.

Sure, it’ll be more expensive monthly than an AWS-from-scratch setup, but you’ll skip a bigger upfront cost. Eventually the economies of scale will catch up and prioritize optimization, but again: ”good” problem.

Don’t Forget to Document Why and When

The safe ways to save we’ve been working through probably look a lot like procrastination, but that’s by design. Building good software means avoiding shortcuts. With a successful product, you’ll need to tackle all of these things sooner or later, and that tends to be easier when you have real customers and a better idea of their needs.

This isn’t an out of sight, out of mind situation, though. Document what’s coming, what the features will take, and signs that they’re coming due. Good problems are only good if you have the runway and specializations to tackle them.