Kneadit: Startup Lessons Learned
Things I learned building an app company in a year.
Our beta of Kneadit launched today! For those that don’t know, Kneadit is a Chicago-centric iOS app connecting users with licensed Massage Therapists. As a customer you can view profiles, shop around for different kinds of massages/prices and book a service in your home or in a spa. As a Therapist on the platform, you gain access to a new client base, get guaranteed payments and have complete freedom to set your own hours and prices.
This was originally a project we initially committed to building with the help of a full time development team. So of course, I ended up spending all of 2016 building it myself as our employees only were able to complete a partial app.
Looking back on the year of hard core development and major setbacks (getting rejected by Braintree and having to rewrite all API code for Stripe) there were many lessons learned. Overall I’m happy we stayed within budget even if that meant extending the timeline significantly. We ended up with a great app that has the potential to be useful to a lot of people, and in the process I wrote a ton of code that we can reuse and build off of for future ideas.
Here are few of the biggest things I learned. Some I already knew, many I didn’t. I’ll reiterate them all in the hopes of benefiting someone looking to launch a similarly complex app.
Contractors all have their shortcomings
Full time people cost a lot and are inefficient, so for a project of this nature going with part time contractors is your best bet. The trouble with part time people is that they often split their attention to different projects and rarely (some do) have what it takes to drive the full completed project over the finish line. We had some fairly talented and smart guys working for us, who just fell off the wagon about 40% into the build (read they managed to get another higher paying contract).
You can avoid this by making smarter hiring choices (or at least limit your risk). Luckily I was not new to hiring contractors and thus structured the deal in a way that we wouldn’t be paying for work that wasn’t completed. In the end we paid for a partial app and received a partial app for me to work off. Not the worst thing.
Payment Processing
I really had minimal experience with payment processing architecture other than building more primitive shopping cart style applications. Kneadit required a transactional model with payouts to a whole bunch of users (our Therapists) oh and by the way you need to vette their identities, take your fees and on and on.
It requires a SIGNIFICANT amount of transactional based code, in the form of a web service. I had a good time learning all that was needed to put together a production quality system. In fact one of the most popular articles on here (must get searched for a lot ) is one I wrote about writing a Flask webservice for Braintree’s integration.
We ended up not going with Braintree (they rejected us refusing to process any payments for our massage Therapists) so I rewrote all of the code to work with Stripe. Stripe has awesome documentation and I was able to work through all my problems fairly easily. Now we have a sophisticated API server that can be used for all future payment processing, hooray!
When working alone be mindful of code and documentation
It’s definitely nice working on your own project alone. You can style how you want, not have to worry about code merges, life’s good. But in larger projects if you don’t document and build things in a readable way you will come to regret. I definitely have cultivated an increased focus on writing code that other people can easily jump in and work on, and that’s benefited us already as a company.
Use an issue tracker
Not only use one, but force whoever may be testing your apps to report bugs through their exclusively. We went through a lot of development cycles with several testers and a lot of features getting built or axed. Having it all somewhere you can browse helps maintain your sanity when you sit down to work each day. If you’re alone this is especially important because keeping every issue and feature request in your head gets draining after awhile. We use Trello exclusively now and haven’t looked back.
Don’t set killer public deadlines they only cause you anxiety. Instead, work on the app every single day.
No more public deadlines for us. With software development (and life) it’s hard to predict timelines especially when you are in uncharted waters. So if you put your reputation and ego on the line due to some arbitrary deadline you’ll likely come to regret it. We blew through several of these until I decided that they weren’t helping productivity and just stressing me out. After that I stopped talking up a pending release to friends and contacts and instead committed myself to working on the code every day. It’s truly amazing the momentum you can build even spending 15-20 minutes squashing one bug before bed each night. I found that the 15 minutes usually turned into 4 hours of cranking away.
Testing (well) takes a lot more time
Everyone’s written tests, and done user testing at some level. My partner and I certainly have done our fair share. One big thing I learned from this is that to test thoroughly requires a whole new level of commitment. Test devices are paramount in creating consistent environments, and repetition within those environments is the only way to uncover all the nasty little oversights you made as programmer. Because our app is so transactional, there were gobs of unhandled exceptions that popped up during testing phases. Thanks to a rigorous testing methodology the final product is that much smoother.
Focus on core functionality and make it reliable
This wasn’t exactly a lesson, but is a core mantra of our firm No Measure Ventures. Ultimately you want to build beautiful software that impresses your users, but it’s not the most important thing. The most important thing is that your application does what it promises in a clean and reliable way. If the concept is truly useful to people then they will certainly overlook the fact that every UI element is animated and perfect.
Notifications
Take the time to build a good automated system for sending notifications. I built out a pretty robust service that sends all confirmation/request emails and can be reused for future apps. Push notifications were there own learning experience and our service for that runs alongside our Parse backend server.
