How Founders Tackle SaaS Differently the Second Time Around

We’re often called on to take the second shot at building a new application. Something went wrong the first time — red tape, politics, approach, know-how, phase of the moon — but the underlying idea still deserves its day in the sun.

Going second isn’t inherently good or bad. Budgets and timelines have taken a hit, but there’s a firsthand understanding of effort and where estimates can spiral. Some of that early project excitement has come and gone, but it no longer clouds what minimum viable means. Lessons have been learned, giving way to a new danger: overcorrecting.

Calling on our experience to date, here’s what SaaS founders change the second time ‘round.

They Focus on the Fundamentals

Not to brag, but I was a pretty mediocre ten-year-old baseball player.

That year, I jumped up to the next division a year early. Not because of my stellar 0-for-5 batting performance in tryouts, but because my swing passed the eye test. At that age, kids tend to skip the fundamentals and favor a home run swing: drop the back shoulder, rely on arm strength, and aim for the sky. They can be really successful with it too, for a time — right up ‘til faster pitching and larger fields turn bad form into liability.

For the second software go-around, founders are extra agreeable to “good form” topics like strategy, architecture, security, and performance. Something was skipped the first time, and the fallout still stings a bit.

A Tighter Definition of “Minimum Viable”

FOMO is real, especially right off the bat. You’ve never really needed heated floors before, but what if you wind up wanting them later? Might as well add ‘em in now.

“Just” adding one more software feature cascades in a hurry. After seeing a few nice-to-haves go sideways, founders let things like rearrangeable tabs and custom avatar builders stay in the backlog. Subsequent builds take the minimum part of minimum viable product a little more seriously.

Valuing Tried-and-True Frameworks

End users (virtually) never care about the tech behind a platform.

Still, new applications are a siren song for the fresh, flashy, and fashionable (and untested) frameworks. Without fail, at scale, the seams start to show — poor documentation, odd design, missing functionality, and bugs that seem weirdly specific to your team. Every technology has its quirks, but first encounters are extra taxing.

Hype can turn into a standard down the line, but if the rookie framework isn’t meeting a specific, unique goal, the broken-in glove looks better for attempt two.

They Add Technical Leadership

Here’s a topic that we’ve been returning to frequently. Non-technical founders have plenty on their plate before taking on development direction, strategy, feedback, and quality assurance. Routinely, though, they give it all a shot on the first go.

Adding a technical lead is a lot like adding a general contractor to a construction project. If a wall is knocked down and new issues spill out, they’re responsible for sorting out a fix that’s friendly to the timeline and budget. Familiarity with what’s possible and the technical details help paper over software’s communication issues.

It’s a new expense, but one that helps avoid the whole starting over thing.

Quick, Deliberate Communication Loops

There’s a recurring red flag that most round-one stories share: communication felt like shouting into a void. The gaps between deliverables were radio silent.

Instead of waiting weeks or months to see if everyone’s on the same page — or in the same book, at least — the second try includes regular check-ins and working in shared environments. GitHub, Figma, and the like all keep progress out in the open.

Sharing More About Features

As we’ve touched on before, even innocuous-sounding features like search can mean very different things to different people. How do we categorize and rank results? Should we provide autocomplete suggestions? Should the results be customized to the user?

Verbosity becomes the name of the game, talking through what’s expected, what’s needed, and setting the stage to properly scope and estimate features.

Seeking Out the Hard Conversations

“I’m not a developer” is the battle cry of every founder who ignores their intuition when a project starts to waver. The first time ‘round is rife with concerns that go unspoken. Assumptions that your partner knows best and everything will work out in the end.

When it doesn’t, everyone’s a bit quicker to tap the brakes in the future.

They Ship Code Sooner

Insert your favorite flavor of “perfect is the enemy of good” here. Endless tinkering before you have customers means missing out on opportunities to learn and test. There’s a “good enough” point where a live application is more valuable than adding layers of polish.

Bringing Customers, Not Ideas, to Investors

App ideas are great, but investors hear plenty. Customers push you beyond “interesting idea” and into the funding-worthy zone. To earn ‘em, you’ll need a shipped product.

It’s doubly true in markets outside of places like New York and California. Our valuation and Series A potential for Code School were an uphill struggle, even with strong financials and a few years under our belts — a sentiment we’ve heard often among other Orlando startups.

Internalizing the Gap Between Interest and Payments

Like playing your band’s demo tape for friends and family, your elevator pitch will get plenty of glowing feedback. Founders quickly learn, though, that there’s a big gap between “that sounds great” and “here’s my credit card.”

It’s another case of needing a live application to learn and test. That, and finding folks you can trust to be honest when you toss Uber for Cats out there.

A Healthy Relationship With Change

No matter how much planning goes into a project, something will change.

It’s not a bad thing; quite the opposite, really, when it’s a reaction to uncertainty that threatens the budget, timeline, or quality of the end product. With experience comes malleability. Keeping an eye on defined goals, the other eye on the roadmap, and communicating as a team sidesteps change becoming a four-letter word.

They Prepare for the Long Haul

With a product in the wild, congratulations, you’re a technology company. That designation comes with a long list of responsibilities from here on out, like sales, marketing, maintenance, and team building. The second time around, founders have a heads up that these needy tasks are lurking in the shadows.

Awareness Trumps Good Code

As someone who’s spent a lot of time obsessing over software craftsmanship, this section hurts the most: Really good design and really good code don’t deliver customers on their own. Industry leaders’ killer feature tends to be awareness, and getting a foothold with a new product takes sales and/or marketing prowess.

Founders that went all in on the build once divvy up the budget a bit differently in the future.

Having the Right Team at the Right Time

The crew that gets you from 0 to 10,000 customers may not be the right crew to tweak performance issues at 100,000. The makeup of a typical team today is different than it was 5 years ago, and it’s different than it’ll be 5 years from now.

Looping back to technical leadership, once you’ve realized something was missing — a specialization, a process, a skillset, or similar — you’re more likely to reevaluate on the regular.

Maintenance is Forever

Keeping an application humming along is a todo list with no end. Like an abandoned structure, going hands-off with a product may be fine for some time. Eventually, though, issues pop up that make a looming cleanup more and more painful — or just flat unfeasible. Since most startups don’t set out to rebuild everything every year or two, one run-in with maintenance woes is usually all that it takes to earmark it from the outset.

Hindsight as a Service

As far as we’re concerned, problem solving is exciting business. Containing that excitement is the trick: It’s easy to track a floundering product back to surprise features, shortcuts, new tech that went awry, and painful DIY attempts. No two builds look the exact same, but there’s a definite pattern to choices made the second time through.