Build Something

Paul Mazurkiewicz
7 min readMar 26, 2021

--

At my startup, we built a weight-plate-motion tracking app using Xamarin, accelerometers, and a raspberry Pi. We installed the app on an old android phone. I told my kids not to touch the phone, the weight machine, or the sensors. The app only ever had one unique user: me.

After our pivot to software, we built a web-based proof of concept, with a constraint solving algorithm and about a hundred exercises that would arrange to the user’s specific needs for rest, physical capability and fitness goal. At its peak, it had seven unique users.

I am still building, but it’s now a bathroom in what used to be a bedroom closet. It will have regular use from dozens of people per year.

The renovations might feel like success, but they’re not getting any more use than the hardware IoT solution we tried to take to market or the AI-driven fitness app we programmed . Home renovations are a cash flow saving; fitness app builds are a deficit. If money is the metric, then one is a success and the other a failure.

My most financially successful builds come from my day job. I’ve built complex systems for national clients. I published daily equity research reports before 7 am every day without exceptions. I migrated terabytes of engineering data from network shares into a content management system. I helped build the infrastructure for how customers order service from a field technician. Those were big impact tasks, but I didn’t own them. The day job provided value, but it didn’t provide purpose.

I often look at my house as my legacy because I spend a lot of time and money working on it. Even still, I’ve never answered ‘what do you want to be when you grow up?’ with ‘a home owner.’ The house, for better or worse, will be where most of my value is stored, but still lacks the purpose I’m looking for.

I walked away from the fitness thing we started for a few reasons and yes quitting was tough because building was fulfilling. But from the get go, I struggled with the values of the organization I tried to incubate. Sensors on weight plates meant a lot of batteries and plastic. A fitness app meant more noise in an already crowded app market. One of the first pieces I wrote for the business was about how exercise alone doesn’t work and a proper diet should come before any exercise journey.

The lesson I learned on building from the startup is to make sure the build aligns with what you want. Rewards always come later. If the pursuit is money, stick with the day job because chances are, it has a net positive revenue stream. If it’s to build value, I recommend real estate and some sweat equity. If, however, building fulfills something else, then by all means, build and be full.

Building With Others

When we built the IoT solution using sensors and a Raspberry Pi, we paid a team to do some of the heavy lifting. We had a vision in mind of what it should be, but what it actually was, we left to others. In retrospect that mistake cost us about 30k. Had we been more clear on the architecture, the functionality, and the end state we would have identified the shortfalls at the beginning instead of the end. Outsourcing was a boon in getting technical expertise in a space we didn’t have much experience in, but it also meant a lot of things we didn’t know, and because of lack of knowledge, we couldn’t agree to some of the decisions taken by the developers. We had an exercise machine with one sensor velcroed to each weight plate. Our expectation of a dozen sensors working in tandem, in reality, resulted in a noisy transmission. We eventually learned that all the sensors sent on a single frequency causing packet loss due to collisions at the Raspberry Pi hub. Had we been involved with the technicalities of the build, we might have been able to catch this.

The lesson I took from this is to be involved in the build at all stages and push back on the builders when they push square pegs through round holes. When leading a build, make sure to build what you need, not what the developers want. Our mistake was getting convinced that the developers knew better because they had domain experience in IoT. Trust your gut, own the risk of being wrong, and get what you want.

Building It Yourself

When we pivoted to a software-centric approach, we built the php frontend, the database backend, and we outsourced the AI rule engine. One of the reasons we shut down was because that was a lot of work for amateurs. It worked — for what it was — but it was never going to see mass market appeal. We had to get a proper mobile developer to make this a working, demonstrable thing. This time we had a functional template of what it should be on completion. Even better, we found a web developer willing to work on this for partial ownership. But pros always have questions and those questions led to more questions and those questions to even more questions. When we looked at some of the answers we gathered, we saw the financial implications, and we chose to walk away. And here is what separated us from successful startups: the intrinsic value of what we were doing was not there for us because our financial opportunities were better elsewhere. For a quick check of profitability of a potential app go to sensor tower top charts and take a look at your product’s potential competitors. When we did this exercise, the yearly revenue of an established competitor app like Bodbot did not look like enough to us to take the leap. The trajectory of fitness app companies — Bodbot had been in business for seven years already — meant we were years away from reaching parity with them to say nothing of the lost revenue of our other opportunities. Building it yourself has to be about more than money. When we shut down, the money did the talking and we did the walking (away).

In my MBA we talked about how the time to start a startup is at the start of your career or at the end. The retired and the unhired start startups. The old do it for purpose and the young do it for money. That is to say, entrepreneurs at the end of careers have money and time whereas entrepreneurs at the start of their careers have time and need money. Maybe if I weren’t middle aged and mid career, maybe I would pursue the opportunity my own business would provide. If I were older, maybe I would pursue a business I believed in more. Build for the right reasons at the right time of your life.

Okay How Do I Build Something?

Start with the putting it out there, think it through while you write it down, and then move on to the artifacts that flesh out the idea, then try it with whatever tools you have available and see if you can make it work with a low fidelity prototype using a web page, excel, or papier-mâché, whatever you have available, but keep going, keep trying, keep pushing forward from that first step because momentum is precious once its arrived and losing it can be devastating. When we built the first time, we mistakenly thought if we build this thing, they will come. Profits (or at least investment) was always just around the corner. The lesson learned is no one is around the corner. Around the corner is another corner. The second time we built, we ran headlong into an existential decision: do we believe in this enough to sacrifice enough to make it a thing? It’s okay that the answer for me was no. It’s another lesson learned. Believe in what you do, and build what you believe.

Questions to Ask Yourself

Why are you building it? The purpose of your build and the general purpose of your business are intrinsically linked, but can be two separate things at times. Building a business to empower people’s personal fitness may require a build to learn how IoT technology works, but eventually it should circle back to that fitness thing you’re trying to achieve. Ultimately, make sure the business goal and the build goal align with your personal goal. If they don’t then as the builder, what’s in it for you?

What are you building? It helps to know if it’s a classic car or a chocolate cake. Sometimes it’s an exploration of what works and what doesn’t. Be clear on the current build, the next build and the build following that. Don’t put the consumer-ready build on the roadmap; it’s a distraction and a disappointment. Customers will come when the product is ready, not based on any roadmap in your pitch deck.

What does it cost? Be clear about the true costs of time and effort against the benefits. Saving some money by doing home renovations may save you half the cost or more of the job, but it will cost you more time and more risk (i.e., plumbing leaks, ladder falls, stubbed thumbs). The same applies to your startup build: what does it really cost? There are opportunity costs to sticking with something that has low payout. There are financial costs to throwing good money after bad. Weigh the true costs of a thing and mitigate.

What is the measure of success? Define the goal of the build and be honest with yourself. Is it for you, a dozen people, or a hundred thousand? Is it so that a dozen people give you a million dollars each? or that a hundred thousand give you $120? If the metric is not money then ensure your organization’s values align with your goal because the difference between success and failure of a build is all about the perception of the outcome. Sometimes a business really is the friends we make along the way. Don’t discount the network made or the relationships strengthened as your build goes up in smoke. If it lifts off to the moon, consider that a pleasant surprise.

--

--