Building an MVP As a Non-Technical Founder (oh ship!)

It's really intimidating as a non-technical founder to figure out how to how to build an MVP when you're just missing the ability to bring your vision to life.

Over the last couple of years navigating Goblins’ platform development, I realized that building a product as a non-technical founder feels a lot like building a ship. That analogy has helped me understand tech architecture, how to choose a tech stack, how to avoid overbuilding an MVP, and when to scale your platform’s power or capacity.

Ultimately building your ship feels daunting but the goal is to simply pick a route forward so that you’re not delaying your vision from ✨existing✨. Your first ship will never be perfect and that’s okay. You just need to build something that’ll allow you to happily (and safely) leave shore and start your journey.

How do you do that? Good question!

Here are my recommendations if you’re trying to build a minimum viable product without a technical background:

Don’t Sweat The Early Direction

I think of the tech stack as the engine of this boat we’re building. It determines what powers your ship and how maintainable it is as you grow.

In our case, the engineer who generously built our alpha in her free time chose Ruby on Rails. Why? Because Rails makes it doable for one person to build and maintain the platform without us needing access to significant capital first. If we’d had more resources, she would’ve chosen JavaScript — but she made a thoughtful call based on the resources we actually had, not the idealized version of where we wanted to be in three months.

Two questions ultimately matter here:

1. Does this stack make sense long-term?

Some stacks let you build fast early, but crumble when you try to scale. Imagine powering a ship by wind- it’s great when you have five passengers but becomes a nightmare when you suddenly need to move a hundred.

2. Can you grow your crew with this choice?

We’ve had VCs really focus on our tech stack and worry about the scalability of hiring. But what I’ve realized is that great engineers aren’t scared of a new language.

Coding is a lot like painting– once you know the foundational components of technique and color theory, switching from acrylic to oil paint is just learning the quirks of a new medium. Or, as one of our community members put it better: “It’s like going from ice hockey to rollerblading”. Thanks for that Goblin Howuf!

When you find a great engineer and they’re really psyched about what you’re building, the tech stack is the last thing they’re concerned about. Ultimately they’ll be more interested in the culture of the team, your vision for the company, and if they’re excited to climb aboard. A good engineering fit will be psyched about the vision and ready to do what they have to to get up to speed.

Determining Your Tech Stack

When you’re choosing your tech stack as a non-technical founder, remember: you’re picking the engine of your ship. Every engineer you speak to will have an opinion about what type of tech stack your platform should be built on and compelling reasons behind why.

You can have dozens of those conversations and still get no closer to a perfect consensus so my recommendation would be:

1. Write down what your platform needs right now features-wise, and get specific. Ie: people will need to create accounts, create profiles, search across existing platforms, we need an admin functionality to review flagged profiles, etc.

2. Do the same but now for the features and functionality you envision being built into the platform 2–3 years from now.

3. Speak to five technical people you trust and ask what they’d choose as their tech stack/architecture.

4. Pick the recommendation that comes up the most and even then, it might not be perfect re: finding 3/3 on the front-end backend pairing. That’s ok!

5. Research what other platforms in your market are using. Sometimes you don’t have to reinvent the wheel (or helm, to stay on-brand with the ship theme)

I know, I know– the decision feels enormous, but early on your real job is again, choosing a direction, not choosing “the perfect one.” Again, progress > perfection because better to have a slightly wonky ship that actually floats than an idea that exists in perpetuity but never gets built.

Avoiding Technical Debt

While you’re building, don’t forget about technical debt– and making sure you’re doing what you can to minimize it. While you may be building an MVP, it’s also important to build in tests, maintenance, monitoring, and deprecation schedules to ensure you’re creating something scalable and sustainable.

I admittedly didn’t know deprecation was a thing until recently- unlike an untouched Google document, a technical platform that doesn’t undergo regular maintenance can fall into disrepair and stop working.

Needless to say, we’re making sure to now regularly scrape off barnacles, check for leaks, and whatever other maintenance we’d metaphorically do to ensure the health of our ship.

Don’t Build a Cruise Ship Before the Gangway

If the tech stack is your ship’s engine, architecture is the blueprint for the ship’s core construction, the hull, rooms, storage, and the way that everything connects to itself.

For the earliest version of your platform, you want to make sure that you are building for what you need now, not what you’re going to need. I learned the hard way that you can absolutely overbuild your MVP.

We once worked with an engineer who architected Goblins like a full-scale cruise ship, something that could theoretically support millions of people. Except you also couldn’t even create an account with a regular email and password

Even without anyone using the platform, it was going to be more expensive to maintain than our original alpha. And with the basic functionality not even working, it was giving… abandoned cruise ship vibes.

Good architecture plans for where you are now and where you’re realistically going next, not the idealized situation five years into the future. Just remember to keep track of your tech debt.

Metrics

I wish I’d known earlier about the necessity to build in metric-tracking because those aren’t magically/automatically available.

Seeing how many sign-ups you get is awesome but it’s even more important to be able to track how many of those folks come back, engage with the platform, and generally get an idea of if there’s sustained interest in what you’re building.

You need to know:

• When people return to the platform

• Why they continue engaging with the platform

• What parts of the platform aren’t capturing user engagement.

• When people drop off the platform.

These metrics will help you understand your user behavior and make adjustments that’ll enhance their experience.

Must-Haves vs. Nice-to-Haves

This is the part that can make or break a young product.

Founders love the future. Engineers love details. Combine those two and suddenly your MVP has a twelve-page amenities list but no working login.

So the most important thing to remember is that your ship (ahem, early product) does not need a waterslide, helicopter pad, or even a chef’s kitchen.

It does need:

• A watertight hull

• A reliable engine

• A working steering wheel

• An easy way for passengers to get on the ship and reasons to stay aboard

Everything else is a “later” problem.

Remember, when building a ship, it would be crazy to debate about the seating upholstery colour without having a structure that floats. But when you’re building a platform, it can be tempting to hem and haw over the perfect design of buttons while the sign-up flow isn’t yet functional.

A simple question to ask yourself constantly: “Will this help us set sail sooner or are we focusing on the aesthetics of a hypothetical ship right now?”

When to Expand Capacity vs. Increase Power

Building and growing the platform is a whole lot more complicated than just making sure you have a functional platform that you add features to. Your development should always be tied to the real-time needs of your platform.

Technical or not, a good founder has to listen for the ship’s creaks. Is it sagging under weight? Is it slowing down under the added weight of more passengers? Are people confused about where to go upon boarding the ship? Each issue tells you exactly what to fix next.

You need more capacity when:

• Users are onboarding faster than expected

• Your database is groaning at peak times

• Your retention metrics are strong and there's organic growth

You need more power when:

• Everything “works” but feels slow

• Workflows drag even when traffic is light

• Your core systems can’t scale with demand or support the building of new features

You need better UI/UX when:

• People get lost in the product

• Onboarding is confusing

• The path to the user's “aha” moment as to your value isn’t obvious

Aye, Aye Captain!

So, fellow non-technical founder, take the above recommendations and confidently make some decisions that'll get you closer to having a functional MVP. Will it be perfect? No, but progress is every perfection and as a few smart engineers have told me, "there's a solution for every problem" so, when you inevitably encounter those later down the line, tackle 'em-- but don't risk not building because you're obsessing over perfection.