0 to 1 in a week: The power of bootstrapping 🛠

At Sparkmate we focus on delivering fast, comprehensive engineering services, with an emphasis on giving our clients functional prototypes in a matter of weeks. We know that velocity is the main key to success for young companies. And though it might take several iterations to have a robust version of a product ready to scale, it is generally possible to get a first operational version in no more than 1 week.

So we sometimes meet clients, generally entrepreneurs already familiar with the concept of prototyping a product and bootstrapping their business, that come to us for ultra fast prototyping. They’re starting to gain traction on the market or they have key stakeholders or customers to convince. They need an elegant and operational solution in DAYS, not weeks.

That's where most engineering / IT firms, design studios or agencies would propose a non-functional prototype like a UX/UI clickable prototype for apps or a 3D realistic rendering for physical products. This might work to win a startup pitch contest but it usually doesn’t win clients. And what matters in the end is clients.

Entrepreneurs bootstrapping their business know that you need time, energy, passion, and hard work to build the right product. It can be terribly frustrating when you don't have the tech and hard skills necessary to do so. For simple digital products, no-code tools are great for 80% of the job. But as soon as you need to build something that is not fully satisfied by the tool, you have to start again because no-code tools rarely integrate with most engineering infrastructures.

And let me reassure you, even when you have hard skills, it's not easy to go from 0 to 1 in one week. At Sparkmate, we call it a rush, distinguishing between a “rush” and the “sprints” of an agile method:

• Sprints are a set of short periods, generally 2 to 4 weeks, during which a list of very specific work has to be completed. A typical project consists of 10 to 30 sprints, one after the other.
• A rush, as we call it, is the prototype of a complete project done in no more than 2 weeks: every core function of the system must be developed during that period.
  

A rush is a single period, and that changes everything.

It’s all about pacing

A rush is a mindset, it imposes a certain pace, it imposes the need for momentum that will keep you going. In order to have a successful rush, you should focus on keeping that fire going, avoiding everything that slows you down, that breaks the rhythm and that might end up stopping you.

Therefore a successful rush needs to met the following requirements:

• It must be a challenge with specific goals (not tasks).
• It must be short, 1 week is good, 2 weeks is the max: if it lasts longer than that, exhaustion will keep you from maintaining your pace and momentum.
• It must be something new: you cannot (or it is really difficult) build tons of momentum on something you’ve already started. Plus, it wouldn’t make sense to rush the 4th wall of a house if you’ve already taken the time to build the first 3 nicely, right?
• The team must be composed of no more than 2 people: time spent on team management can break your momentum and pacing.
• You need all the necessary inputs to meet the challenge, and there must be no, or very few, external changes during that time (such as a change in the requirements): again, the time spent adapting might kill your rush before you achieve anything that can be showcased.
  

At Sparkmate, we always share those principles very clearly with our clients, in order to avoid any misunderstandings.

How do you keep the momentum?

The momentum of your project is the impetus gained as your project moves forward. So the answer is pretty straightforward here: never stop moving forward. Easy, right?

Let’s deep dive into some details. What you want to foster is this impetus, the energy with which a body moves, and this energy comes from you. That’s why we said earlier that a rush is about mindset and that’s why the requirements described above are so important. Of course, good tools and methods can help but the only critical success factor is your determination and your perspicacity.

The trick here is to not let yourself go backwards, which sounds easy but can be actually quite difficult in practice. There are a lot of ways of “going backwards” and that’s why after each rush we recommend that you take some time and ask yourself if things went wrong, where, and how that could have been avoided.

However here are a few rules that we at Sparkmate try to follow when we have to bootstrap a prototype in one week:

• Whatever you do, do it only once: don’t start a task that requires something else to be finished - if you program a function, make sure you will not need to come back to it later, if you solder an element be sure to take the time to make it clean. If you need to go back to something you already did a few days ago, it will kill your momentum.
• Spend 15 to 30 minutes planning your day, every day: spending that time will force you to realize what progress you’ve made and will help you prepare the right order for your next tasks.
• Be accountable for your work, spend 15 minutes each day to sum up what you've done and what you still need to do, updating your roadmap! And share it with your team, your friend, your stakeholder, your client… keep in mind that telling someone what progress you made day by day will help you move forward.
• Take a wild guess about the time needed for a task before starting it, and ask for help once that time has passed: doing everything by yourself can feel like an achievement, but it’s not what matters during a rush. The one goal is to get it done. Remember that and ask for help before getting stuck.
• Find a comfortable workspace to help you focus and don’t forget to take breaks, eat and sleep.
  

The right blend of rush and standard development:

A rush is something that can be really exciting, but nothing is worse than doing a rush on a project that should have been developed in a more standard way. Also be aware of how a rush wears you down - we wouldn’t recommend executing several rushes in a row.

If you’re into exercise, you know that it’s important to alternate fast-paced and slow-paced periods. The same rule applies to product development. You cannot spend 6 months doing rushes.

And bear in mind that the definition and the methodology of a rush is very personal. What works for me and for us might not necessarily be the best for you. Building a project in a week does not give you the time to take a step back, technically, sure, but also personally, for example regarding how you manage pressure or productivity. Take some time as soon as possible after the end of a rush to improve your methodology.