How to Build Any Product in 12 Weeks

You can build just about any* product in 12 weeks or less, from idea to in-market. But, to do it, you have to approach the problem in a very particular way, and think carefully about the decisions you make.

One of the things we do at Sourcetoad is deliver MVP products to customers in a 12-week, flat fee engagement that helps startups and enterprises manage their risk and get to market faster. It’s taken us years to develop this approach, and I’m going to share some of the secrets that make it work. It’s what allows us to deliver so much value, so quickly, while keeping costs super reasonable.

Something we’ve learned doing this for decades: building products quickly is as much, if not more, about your approach and philosophy about your initial version than it is about specific hacks, timesavers, frameworks, or languages. Much of the battle is already won if you frame your MVP correctly in your mind. This is the primary value we give to our clients – helping them focus correctly and make the right decisions to get to market ASAP.

So, if you want to build a product as fast as you possibly can (and to slightly misquote Jack Nicholson’s character in A Few Good Men, is there any other way?), here’s what you have to do.

Stop – Do not continue if you don’t believe this.

This is a truism: the first version of what you build, no matter how well thought out, will almost be guaranteed to be wrong in a number of small ways, and possibly one or two big ways. You have to believe this. Finding out how you’re wrong, and fixing that, is the entire point of an MVP. If you don’t believe this, then nothing in this article will help.

Your MVP is About Testing an Assumption

When you’re building the first version of your product, stop and think: what are you trying to prove here? Every product in the world comes with an assumption – some way of doing something you think is better, more efficient, more interesting. But, it’s just an assumption. You don’t know that the thing you’re planning on making will actually do what you want, the way you want it to. Otherwise, everyone would just give you a billion dollars, no questions asked. If they’re not, then they probably have questions. And if they have questions, you should too.

So the first thing to keep in mind is that the purpose of an MVP is to find out if you were right or wrong about your assumption, all while spending as little money as possible to find out.

Building an MVP is an exercise in risk management. Building anything is risky. It takes time, money and good guessing to make something that people actually want to use. And most people – an overwhelming amount – fail.

Find the Core and Reject Anything Else

If building an MVP is about testing an assumption, then the first step in building it is to find out what the assumption is, and actively discard any plans of building anything else not directly related to that assumption until way later. I call this the core of the product. It’s why it exists.

Some examples of the core of popular products:

• The core of AirBnB is the idea that people might stay with other people instead of hotels.
• The core of Twitter is the idea that people might want to broadcast thoughts to friends throughout the day.
• The core of Slack is the idea that people who work together might prefer chatting instead of emailing all the time.

Notice that all of these focus on a single assumption that building a simple solution for will solve:

• All AirBnB needs to do is build a booking system that takes public submissions from regular people. Favorites, reminders, lists, and other goodies aren’t required to test this.
• All Twitter needs to build is a way to send a message to a handful of people following you. Favorites, lists, stats, and fancy profiles aren’t required to test this.
• All Slack needs to build is standard chat, packaged in a way that businesses might buy it and use it. Public and private channels, canvases, and bookmarks aren’t required to test this.

Now, once you know what your core is, you need to make a decision as to whether it’s a technical core, or an experiential core.

A technical core has a problem statement that sounds something like: “We think that we can connect/integrate/process this data/system/technology and if we can, then that’ll let us do this cool thing.” The key here is that you don’t know if you can technically do what you want to do. You might believe strongly that you can, but if it’s not very obvious how to do it and how it’ll all work, you still have a technical core problem to solve.

When you have a technical core, the first thing you do is solve the technical problem. This is your biggest risk area. You can build all the UI in the world, and it can be gorgeous, but if the thing doesn’t do the thing, then you’re dead. You have to prove it works first. This means building with no user interface, or very little. No custom design, no caching or scalable architectures, nothing. Just the bare minimum code to make sure it works. Again, if it turns out you’re wrong and you can’t do it, you’re dead. Only spend time and money solving the next problem.

If you’re sure you can do what you think you can technically, then you most likely have an experiential core. This is characterized by an arrangement of features and journeys across pretty standard stuff, but the orchestration of the things is where the real magic happens. If this sounds like your product, then you need to prove that this orchestration and journey really comes together the way you think it might. For what it’s worth, experiential cores are the easiest to be sure about, and the hardest to actually be right about.

So when you have an experiential core, you have to build out the experience. This means building out the basic set of interactions (for an app, usually screens or UIs) that represent the collection of the most important things needed to deliver the value. These should be the bare minimum to test the experience and collection of features, and no more.

Beg, Borrow, and Steal Everything You Can

Remember the assumption we’re testing? Most of the stuff in your product has nothing to do with that assumption. You don’t assume you have a better way to log people in, probably. You also don’t assume that you’re going to be more successful because of some esoteric dev framework you just heard about, hopefully. So, for anything that isn’t directly related to proving or disproving your assumption, you need to see if you can borrow it, buy it, steal it, copy it or otherwise acquire it with little to no effort or cost.

This means you should use some kind of starter kit or template to scaffold your app. You need to use as many off-the-shelf component libraries and plugins as possible. If the first thing you do when building your product is create a new blank file, you’re doing it wrong.

Steal everything that’s not core to your product, from whole pages, like login pages, to page-level components. Do not build tables or lists from scratch. Everything should be off some shelf if you can find it. Leave your precious resources for working on the parts that are unique to your product, in other words, the core.

Replace Documentation with Demos

There is very little that needs to be written down about a product, except for anything that directly goes into marketing, or into explaining how to build or understand the product to someone not on the core team.

Documentation is one of the sneaky killers of MVP speed, because it feels useful and productive, but in almost all cases, spending the same amount of time building the product returns 10x the value.

In a fast-paced MVP sprint, there’s no time for weeks of wireframes or visual comps, or lists of features, or specs, or even for detailed roadmaps. A small team, working tightly on a product together every day is self-documenting, in that the tribal knowledge in the group satisfies the needs for day-to-day operations. For things like design, peer collaboration between designers and developers, in real-time, working together to co-design an interface in production code is one approach we use to go straight from an idea to a built thing, skipping the entire documentation process.

Use AI to accelerate EVERYTHING

This is no better time to build a product than right now. And right after I publish this post, the same will ring true every time you read that sentence. Tooling and processes for building products gets better yearly, and AI is the latest massive powerhouse in product development tooling.

There’s no doubt that AI-assisted development is the future of building products. Things like Cursor and Aider cut the time to create products down by orders of magnitude. Becoming proficient with this new way of creating products is required for any team that hope to compete in the future. If you’re tasked with actually doing the work to pull the product together, then these tools should be in your arsenal today.

Make Sure You Have Experienced Leadership in Place

Building products looks easy, and in this article I’ve talked about ways to cut through the static and get a product to market quickly, and this is learned from years of finding out the wrong ways to do it. The truth is, building things is hard and complicated, and if you don’t have direct experience bringing new technology to market, you’ll likely have a more difficult time getting a quality product into the world. Whether you hire someone on your team with this experience, or bring in an expert team like Sourcetoad, make sure you find people with experience to help guide you along your path.

*yes, of course there are exceptions.