That Startup Life: The Covid Special A Technical Co-Founders Journey
For the past few months now I have been working deeply on an incredible opportunity called LittleNewt (https://littlenewt.com) Now on the surface, Automating tax stuff for CPA’s, it may not sound the most thrilling, but building a fully automated system from scratch to do this is a bit more so. A startup is challenging to begin with and we decided to make it a bit harder by throwing a dash of covid into the equation, not by choice certainly, but it is what it is and a covid startup does have some advantages, namely – focus. When there isn’t anything else to do it becomes pretty easy to focus on building something.
In 3 short months, we took a product from an idea and a few notes into an automated platform that does some pretty nifty things from a few different perspectives and stands to be rather disruptive to a market that still looks like the world runs on windows 98. Now that I am coming up for a little air I thought I’d detail a bit about the process, startup life during covid, and general tips, tricks, hacks, ideas, philosophies, and reasonings that lead from an idea to a working product and some of the steps to get there.
When I design systems I like to begin with the idea – what are we trying to accomplish. I have to view the project from as many perspectives of the user as I can muster both internal and external. The idea should be something simple “Automate Tax work” a building block to build out of. If your system is comprised entirely of tiny blocks dedicated to automating tax work then when you finish building something those same properties (and others) should emerge from the finished system. This is how nature operates and how our perception of reality is formed so the benchmarks out there indicate the method works!
After the idea is clear and simple the process is to set the scope – what sort of rules are going to confine our system – what sort of software do we have to use, what sort of interface are customers used to, what other products are doing, does the market place any bounds, regulations, etc. You likely won’t know them all, but having an idea of what sort of barriers you are going to encounter during the process allows for better planning, fewer revisions, and a faster product development cycle.
So now the stage is set we’ve defined the terrain and we know the destination now to walk the path – but wait, we’re making the path as we go.
This step of the process I find will define a product, what is our process?
For me, this decision is always easy – I have 20+ years of a litany of skills and know I can develop an MVP solo – it won’t be some work of gorgeous elegance, but it won’t crap out at the first sign of mud either. If you are a technical co-founder or aspiring to be, this is the wheelhouse you want to inhabit. Why? Even if you can put the spit and polish on something your job as the technical co-founder is blazing the trail, not making it look pretty for people to follow you. This process when viewed from above will look like a river moving through the land moving this way and that with thousands of little tributaries branching out (dead ends, not right nows, maybe laters) with the overall path of the river itself representing the system being developed.
Using natural systems as inspiration isn’t exactly new hat, but I find it often overlooked for the flavor of the month acronym, some holy grail 1 stop language, and endless wireframes. Why is there often a disconnect between your technical people and non – especially in startup land? Because there is often a disconnect from reality – we focus so much on the esoteric ideas of our roles that we forget they aren’t so complex – perhaps there is an onus in society that drives this behavior, but as trailblazers, it becomes part of our job description to find the path of least resistance and remove what clutter we can so the waters flow (that’s cash for those of you who have had too much metaphor).
At this stage, the mind will churn and stacks, implementations, off-the-shelf, open-source, and proprietary solutions will begin to mingle and a solution to the problem we just created begins to take shape. Time to do some work and begin building the foundations of your system. Start broad, use off the shelf, and open source as much as possible even if a future iteration will re-write the functionality. Aim to be custom coding as little as possible in the beginning – even if your meta power is super coding you will still bend the knee to the almighty copy & paste find & replace. There is a saturation limit here that will vary depending on your project. Plugging in 120 different libraries may be fine for a prototype, but you should probably refactor the idea for an MVP.
Solving this equation efficiently and elegantly is what defines a technical co-founder and can often directly impact the success of any startup.
Patreon is a great way for me to fund this entire adventure from gear to race buy ins and maybe even a smidge for my time – join the party for as little as $1 a month and be a part of the journey!
Sweatcoin is an awesome concept of a crypto-currency based system that rewards your to move around! Get paid to walk & run, get special offers for your hard earned sweatcoins!
I just started up a youtube channel to document this adventure. It is more than just another running story and encompasses the larger adventure that is the past 12 years of my life culminating into now.
The philosophy that is inspiring this journey, check out the preview my clocking button! This is my first book and is self published you can order on this site or amazon!