How Businesses Get Software Built

Software projects often start with a feeling rather than a plan:

• “We can’t keep doing this in spreadsheets.”
• “We’re dropping work because things fall between systems.”
• “Our competitors have an app.”

This Thanksgiving, we at Confederated Technologies, Inc., are grateful for the opportunity to pull back the curtain and expose the inner workings of how businesses get software built today. We hope this information helps someone find the right solution for them. This is a guide to the main ways businesses get software built today, what each option is good at, and the tradeoffs are getting made whether anyone realizes it or not.

Quick guide:

• Stay manual if you’re still figuring out your process and volume is low.
• Buy SaaS if your problem is common (CRM, billing, scheduling, etc.).
• No-/low-code if a motivated non-technical person can own a simple internal tool.
• Freelancers/agency if you have clear, bounded projects and no internal team yet.
• In-house team if software is becoming core to how you make money.
• Hybrid if you need outside help but want to grow internal capability over time.

A Simple Way to Think About Your Options

Before we list options, it helps to have a mental model. When you’re thinking about software for your business, four questions should drive your decision-making process:

1. How unique is your problem? Is this something many businesses face, or is it specific to your domain or how you operate?
2. How critical is it? If the system goes down or behaves badly, do you lose convenience, money, or customers?
3. How much change do you expect in the next 12–24 months? Are you stable, or are you still figuring things out?
4. How much internal technical capacity do you want? Do you consistently find yourself encountering problems that having one more full-time software engineer would negate?

Your answers to these questions will point you toward one way of getting software built or another, so let's walk through some of the options and see what they're good at and what tradeoffs they require.

Option 1: Keep Things Manual (Spreadsheets, Email, and Memory)

Most businesses already have a “system” long before they talk about software:

• Shared spreadsheets
• Long email threads
• Chat messages and phone calls
• One or two people who “know how it all really works”

This is still an option, and sometimes it’s the right one.

When This Is Reasonable

• You're still experimenting with the process or building the business systems.
• You’re not yet sure what actually needs to be systematized.
• Your volume is low enough that the friction is noticeable but not overly cumbersome.

Upsides

• No up-front software cost.
• Maximum flexibility: you can change the process any time.
• It can help you uncover more ideal workflows before you encode it in software.

Downsides

• You pay in time instead of money: copying data, following up, correcting mistakes.
• Data is scattered across tools and people; reporting becomes difficult.
• Risk concentrates in individuals; if someone leaves, their version of the process leaves with them.

As a practical litmus test, if your team is typing the same information into multiple places, or you can’t answer a basic question about your business without hours of digging, you’re probably past the point where “manual” is serving you.

Option 2: Buy Existing Software (SaaS and Off-the-Shelf)

The next step up is buying something that already exists: CRMs, ERPs, helpdesk tools, project management apps, and industry-specific platforms.

Best Fit

• Problems that are not unique to your business, such as:
  • Customer relationship management
  • Invoicing and billing
  • Scheduling and basic inventory
  • HR, payroll, and ticketing
• You want working software in days or weeks, not months.

Upsides

• Fast to adopt compared to a custom build.
• Usually cheaper up front than building from scratch.
• You benefit from improvements funded by a whole customer base, not just you.

Downsides

• You may need to adjust your process to fit the tool rather than the other way around.
• Connecting several tools can become fragile or manual.
• Many small subscriptions can quietly grow into a significant monthly cost.

If your need looks like a problem lots of companies share, buying something that already exists is usually the most responsible starting point. Custom software is rarely the right first move in that situation.

Option 3: Use No-Code and Low-Code Tools

No-code and low-code platforms let you build simple apps and workflows with visual builders instead of traditional programming. You can think of them as “supercharged spreadsheets” with forms, automation, and simple databases.

Best Fit

• Internal workflows: approvals, checklists, data capture, simple dashboards.
• When a non-technical team member is motivated to own and maintain their own tool.
• Prototyping a system you might later rebuild as a custom application.

Upsides

• Very fast from idea to a working tool.
• Close to the problem: the people doing the work can shape the tool directly.
• Helpful for discovering what fields, steps, and reports you really need.

Downsides

• Performance and complexity limits tend to show up as the tool grows.
• Easy to create fragile “logic islands” that only one person understands.
• Vendor lock-in: migrating away later can be complex if the tool becomes central.

A useful way to think about it: no-code and low-code tools are like very strong duct tape. They are excellent for experiments, temporary joints, and modest internal tools. Problems arise when an entire building ends up held together by duct tape.

Option 4: Hire In-House Developers

At some point, software stops being “that project we did once” and starts becoming part of how you do business. That’s when many organizations consider building an internal product and engineering team.

What It Looks Like

• Software engineers on your payroll, possibly alongside a product manager or technical lead.
• Over time, this grows into a proper product/engineering department.

Best Fit

• Software is becoming core to your business model, not just supportive.
• You expect a long-lived product with continuous evolution.
• Non-technical employees can no longer understand, maintain, or expand upon the tools they nominally own

Upsides

• Deep understanding: in-house teams learn your business in detail.
• Long-term ownership and continuity of your codebase and systems.
• Closer alignment between business direction and technical decisions.

Downsides

• Hiring good engineers is slow, expensive, and challenging.
• If you only hire one or two, they can be isolated, overloaded, hard to retain, and prone to stagnation.
• Without experienced, full-time technical leadership, complexity can accumulate quietly.

In-house teams are strongest when you treat software as a long-term capability, not a one-off project. They function best when they are well-supported by other technical teams, such as DevSecOps (Developer Security Operations) and UX/UI (User Experience/User Interface) personnel. If you’re not yet sure whether you’re building a real product or just fixing a specific pain point, you probably don't want to make this move yet.

Option 5: Hire Freelancers or Short-Term Contractors

Freelancers and contractors are individual professionals you bring in for specific projects or time periods. They can be a powerful way to add capacity or gain access to specialized skills.

Best Fit

• Clearly scoped, bounded projects, such as:
  • “Connect System A to System B.”
  • “Add online payments to our existing application.”
• Temporary skill gaps on an existing team.
• Short bursts of work where hiring full-time doesn’t make sense.

Upsides

• Flexible and relatively fast to engage.
• Access to niche expertise.
• No long-term headcount commitment.

Downsides

• Quality varies, and vetting can be difficult without technical expertise.
• Managing multiple contractors can add coordination overhead.
• When the engagement ends, ownership of maintenance and future changes is not always clear.

A useful analogy: freelancers are like specialist mechanics. They’re excellent when you know roughly what needs fixing. They are less ideal as the sole long-term owners of a complex, evolving system unless you have strong internal technical leadership directing the work.

Option 6: Hire a Software Company, Agency, or Consultancy

Another common route is working with a software company that brings a team and a delivery process. Typically, there is a period of discovery and design, followed by implementation, testing, and deployment. In some cases, they also help operate and support the system.

Best Fit

• You need custom software that doesn’t fit existing tools.
• You don’t currently have the desire or ability to staff another software engineering team..
• You want a structured approach instead of ad hoc work.

Upsides

• Access to multiple roles as a package: architecture, development, testing, DevOps, and more.
• Experience drawn from other projects and domains.
• You can move quickly without building a permanent internal team first.

Downsides

• You are renting the expertise, not building or retaining it as a business capability.
• If you do not plan for handover, it is easy to become dependent on a single vendor.
• Different firms have very different philosophies; some optimize for shipping something quickly, others for long-term maintainability, and their values and how well they align with your business goals may not be self-evident.

When you talk with software firms, one good question is: “How would you approach handover if we later want to bring development in-house or work with a different vendor?” Their answer will tell you a lot about how they see your relationship.

Option 7: Hybrid and Shared-Responsibility Models

Not every business chooses between “do it all in-house” and “hand it all to someone else.” In practice, many successful software efforts are hybrids: internal people and outside partners sharing responsibility in a way that fits the business and the moment.

These hybrid arrangements can look very different from one another. Here are three real-world examples that illustrate how varied they can be.

7.1 Codecept Software Pty Ltd

In some arrangements, the outside company’s value is not only building software, but also helping your own team grow while that software is being built.

Codecept Software Pty Ltd focuses on native application development with C++ and QML. They do not just write code and leave; they help you build your application while also mentoring your staff and shaping a learning path for your engineers. Although it's possible to hire them to do only one or the other, they excel at simultaneously building up your product and your engineering capabilities.

This kind of hybrid model is a good fit if:

• You need specialized expertise but do not want to always depend upon outside experts.
• Your team has the capacity to collaborate with specialized personnel and learn from the experience.
• You expect to have ongoing development related to the application and want a sustainable path forward

7.2 Red C Tech, LLC

Another arrangement separates responsibilities by specialization. Your own team (or another partner) focuses on the parts of the system that customers and staff interact with, while the specialists focus on the environment those systems run in.

Our example, Red C Tech, focuses on the cloud and DevOps side of the house, helping companies set up and manage cloud infrastructure, automate how software is deployed, and keep costs under control. Instead of building applications themselves, they work closely with your engineers so that when your team writes code, it runs in a well-designed, reliable environment, and this all happens inside your own organization's network.

This type of partnership can make sense when:

• Your developers are doing well in their primary domain but don't have the bandwidth to handle an adjacent domain.
• You want full visibility into the project and can supervise the partner's access to your systems.
• You intend to use the resulting system component without significant modification for a prolonged period.

7.3 Confederated Technologies, Inc.

A third example is a partner that behaves less like a narrow specialist and more like an additional software engineering department that works alongside your business.

Confederated Technologies helps companies build and connect the software they rely on: online portals, the behind-the-scenes systems that power them, and desktop or mobile apps that talk to those systems. We work alongside your team, take care of the project from initial idea through launch, and set up the day-to-day tools needed to run it. When things are stable, we hand everything over with clear documentation and stay involved for a while so your staff can take confident ownership.

This style of hybrid model is helpful when:

• You have important software to build or connect, but not a full internal team dedicated to it yet.
• You need meaningful reporting on the project but cannot properly supervise the partner's access to your systems.
• You want one partner to coordinate all the moving parts instead of juggling several vendors or freelancers.

What to Look For in Any Hybrid Arrangement

Whether you work with a mentoring-focused partner, a cloud and systems specialist, or a department-style partner, the most important ingredients aren’t technical buzzwords. They’re clarity and fit:

• Clear responsibilities: who decides what, and whose tools and systems are used where.
• Shared definition of success: what “good” looks like one, three, and five years from now.
• Ownership and maintenance: who owns the system long-term and how handover will work.
• Knowledge transfer: how your team will learn enough to feel comfortable owning it.
• Respect for your context: partners who adapt to how your business works and care about your outcomes.

A Concrete Example of Choosing a Model

To make this more tangible, imagine a 25-person service business that has grown quickly. Today, everything is run through a patchwork of spreadsheets, email, and a couple of SaaS tools. The team is feeling the pain:

• Leads are tracked in multiple places.
• Scheduling conflicts happen regularly.
• Reporting for the owner takes hours of manual work each month.

They know they need something better, but they are not sure whether to build or buy.

If they choose to stay manual, the pain will likely increase as they grow. If they jump straight to hiring a full-time engineering team, they might commit to a long-term cost before they are ready. If they ask a freelancer to “build us a system,” they may get a tool that works initially but is hard to maintain or extend.

A more deliberate path could look like this:

1. Map out their processes and try to move as much as possible into off-the-shelf tools and simpler automations.
2. Identify the parts of their workflow that are truly unique to how they operate.
3. For those unique parts, consider a custom solution built either by a software company or a hybrid team, with the understanding that an internal product owner will emerge over time.
4. Plan from the beginning for who will own the system one, three, and five years from now, even if they rely on external help.

The “right” answer will be different for each business, but approaching the decision in this structured way produces better outcomes than reacting to the loudest pain point.

A Simple Decision Guide

As a rough guide, you can think in terms of size, stability, and how central software is to your work.

If You Are Under About 20 People

• Your main pain is messy processes and scattered data.
• You are still solidifying how you want to work.

Start by improving the process itself and using off-the-shelf tools or modest no-code solutions. Custom software may be premature, and you can learn a lot from simply tightening your existing system.

If You Have Hit the Limits of SaaS and No-Code

• Your workflows are stable but unusual enough that tools no longer fit well.
• Your team spends real time fighting the tools instead of serving customers.

This is where custom development starts to make more sense. That could be a software company, a carefully chosen contractor, or a hybrid arrangement. Whichever route you pick, ask early how they approach long-term maintenance and handover.

If Software Is Clearly Becoming Central to Your Business

• Revenue is increasingly tied directly to your systems.
• You see a long road of features and improvements ahead.

Begin planning for in-house engineering capabilities, even if you use external help as a bridge. Think of software less as a one-time project and more as an ongoing function of the business, like finance or operations.

Closing Thoughts

Every option for getting software built comes with tradeoffs. There is no universally correct model, only models that fit better or worse for where your business is right now and where you want it to be.

However you choose to proceed, it is worth treating this as a strategic decision rather than a line item. The right choice should match the uniqueness of your problem, the criticality of the system, the amount of change you expect, and the level of technical capability you want to build internally.

If, a year or two from now, you can look back around Thanksgiving and say, “That project made our work calmer and our decisions clearer,” then you probably chose well.