How Big Should Your Software Partner Be?
Kicking off a new application comes with a list of decisions longer than a drugstore receipt. Build it, buy it, or find it? What’s the best tech stack? Which features does this phase need? What’s our budget? And so on.
Hidden in there is another call to make: If you need to hire a software firm, how big should they be?
A five-person shop whose site spends a lot of time on the office dogs, the twenty-five-hundred-developer institution with enough services to fill a novel, or something in between? They’re all perfectly capable of succeeding (fortunately), but the journey varies. It’s a question of process and fit — which path pairs well with your expectations and style?
For this article, we’ll channel Goldilocks and make some comparisons. Two disclaimers worth keeping in mind as we check on the porridge:
- Every firm’s a bit different. We’re generalizing around trends and discussions amongst agency owners, but those tendencies won’t describe everyone.
- Envy Labs falls in the small software company category, but I’m not aiming to convince anyone that small is the right fit for every occasion. (If anything, I’m in danger of being overly critical.)
Let’s take a look at topics where size plays a role — or, perhaps surprisingly, doesn’t.
New Application Availability
Timelines and that “when can you get started?” question kick everything off.
Like your favorite tiny local restaurant, firms on the smaller side have a limited number of places to sit or stand. You may find a table right away, or you may face a lengthy waitlist. Without a reservation, it’s a judgment call on how long you’re willing to stick around for something specific.
On the flip side, larger shops often leave some percentage of capacity free (anecdotally, I’ve heard 10–20%) for new business. The most-requested start date for projects is yesterday, and they’re in the best position to deliver on immediacy.
There’s nuance, of course. At Envy Labs, development capacity is the common bottleneck, but we’re usually able to make progress in strategy and design to compensate for the wait. Agencies (big and small) also maintain a network of freelancers and/or similar firms to assist during peaks. For some companies, project-based hiring is even an option — one that we aren’t a fan of, but that’s an article unto itself.
Availability is a conversation, regardless of circumstance. Before reaching out, take a realistic look at your calendar of needs, and weigh whether or not you’d like potential partners to keep work in-house.
Contracts and Custom Software
It’s difficult to predict, forecast, and staff unique engagements, and custom software is as unique as it gets. The desire for predictability correlates with company size: The services of bigger firms naturally move towards productization. Aiming for repeatable offerings helps with high-volume sales, team management, and collecting useful metrics — all core to large operations with aspirations of growth.
The drawback, somewhat crudely, is that it can feel like your idea is being put in a box. Things like time, cost, team size, and process may be predetermined by a service offering rather than nuance.
Smaller companies sit closer to the bespoke end of the spectrum, able to look at their smaller number of total contracts with a unique lens. Some custom sprinkles in the process may suit your needs, but that doesn’t mean a bespoke approach is strictly better. Its pricing and timelines are much more wishy-washy: Boxes are predictable, but their contents are not.
It’s like picking between a chartered tour with dozens versus tagging along with a local guide.
Similar Software in the Portfolio
Bigger companies typically cover more industries, so finding a firm that’s done similar work isn’t always tied to throughput. Size comes with breadth, though: you’ll get a wide array of experience and a lot of team members to pull insights from, even if they aren’t directly attached to the project.
Smaller organizations aim for deep knowledge to make up the gap. Teams like Envy Labs punch above their weight in specialized fields (educational technology and life sciences, for us). There are fewer team members to poll for knowledge, but it’s more likely that you’ll get the same group of contributors if there’s an example piece of work you like.
In the end, it’s (surprisingly) a bit of a wash — you can find related projects across the size spectrum, and it’s worth looking at both for that all-important case study that catches your eye.
Pricing for Equivalent Software Experience
Here’s a tricky category with an important lead-in: Size doesn’t necessarily predict the total cost. The economies of scale (large) versus reduced overhead (small) keep pricing closer than most would otherwise expect.
When it comes to equivalent experience, though, we’ve seen lower hourly rates for senior-most individuals at smaller firms. There’s less to account for: layers of management, covering for that 10–20% free capacity, overall operating budget, and so on.
Your mileage may vary, but we typically see all this manifest as lower overall blended rates for big companies versus a lower cost for senior talent at small companies.
The Process Behind Software Development
When we get into process and the day-to-day, the differences lend themselves better to lists. For a smaller group, you’re looking at:
- A limited, set project team of familiar faces (turnover willing).
- A recommended process and communication style, but the ability to defer to your organization’s standards.
- Flexibility in change, lent to the bespoke nature of the agreement.
- Support for smaller asks and limited engagements.
The key item here is limited project team, tied to two reasons:
- More of any specialization (strategists, designers, or developers) comes with diminishing returns, so keeping the headcount low maximizes a budget.
- Companies committing too many people to a project introduce a concentration risk. That idea of too many is proportionally easier to hit with a smaller group.
So, a general feeling of small, nimble, and the ability to take on shorter tasks. Flipping back to large organizations, here’s our final list of commonalities:
- Stronger opinions on the how, and more direct guidance on how to get started.
- The ability to ramp team count up and down at will.
- More team members “behind the scenes.”
- Pushback against change that breaks out of productized services.
- Support for projects of any size.
This section largely follows along with the differences in contracts: Bigger firms are looking for bigger, repeatable engagements. There’s a level of predictability and guidance in there that removes guesswork — how that weighs against the opposing approach of flexibility and access is in the eye of the beholder.
Communication Styles and Hats Worn
As business takes a hard turn towards virtual relationships (out of necessity), we’ve actually seen the largest uptick of local interest in our existence. For some leaders, the ability to drive over and talk to a live human flavors their choice of partner.
It’s a preference that carries through to general project communication, too. All of our team members talk directly with stakeholders, and that direct line — like having our CEO help with server administration — is a trait some clients value. As a small team, we’re a collection of folks wearing many hats.
Like everything else we’ve discussed, though, it still comes down to preference. There are equally as many decision-makers, organizations, and tasks that favor a large team behind a single point of contact. It’s streamlined, predictable, stable, and avoids situations where different people have different marching orders.
The funneled style also lends itself better to models like staff augmentation and a contract-to-hire arrangement, especially when consulting isn’t a key deliverable.
Sizing Up Potential Development Partners
Cost, approach, flexibility, communication — everything in software development exists on a spectrum. Every firm’s a little bit different too, hence the record number of generalizations and hedging words that I’ve needed to put this article to paper.
Picking the right partner includes a look at their size and how that’ll impact the idea-to-delivery journey that you’re setting off on. If your next question is “what am I getting into?”, take a look at our whitepaper on working with an outside software shop.
Friction in Interface Design: Slowing Users Down (on Purpose)
Despite what you’ve heard, interface design friction is not always a bad thing. Learn about the right away to add friction in experience design.