Lessons Learned from Sakani: Early Startup Validation Development Strategy

8 December 2016

For my first post on ashour.ca, I thought I would write about one of the most important things I learned from co-founding a startup. In late 2012, I went head-first into a Real Estate Website startup, Sakani, as CTO and Creative Director. Initially, I was in over my head. Many of the things I learned as a developer working in corporate didn’t apply to the extremely lean and agile style of early startup application development, and I had to learn, and unlearn, a lot quite quickly. I wanted to share some of these lessons here.

Set Expectations Early

I’m the cautious, detail-oriented type. It’s probably why I love design and code. Working in the high risk, high reward startup sphere, I’ve learned to find my balance and to live more like a “kite in the hurricaine”, to quote Zen master Charlotte Beck. Still, application development is an intricate balance of art and science, and if you’ve worked on a sizeable software project for a while, you know that good architecture, best practices, and timely refactors can keep you and your development team sane. But here’s the thing: not everyone knows that!

My co-founder came from a financial background and had never worked in app development, so I had to introduce him to concepts like technical debt and refactoring. This worked to our advantage, since he was more willing to wait on features when he knew that if we didn’t rework a part of the system, things would go south. Remember that your partner, co-founder, or boss may not know anything about software development. So share your process early and often until he or she becomes more familiar with it. This saves a lot of friction.

Run With a Prototype

Speaking of technical debt, don’t be afraid to take some on in the very early validation phase of a tech startup. It took us about six months to launch the Sakani web app, and that was way too long, given that Sakani was not that complex in its early days. Lean Startup thinking is all about eleminating risk, which means getting something in front of real customers early and getting their feedback. You are validating many assumptions at this early stage, and you need to hit the ground running very quickly.

As technical lead, I was way too finicky with things like unit testing and app architecture early on in Sakani. What we should have done is create a simple prototype, without much regard for architecture or best practices, and launched it within one or two months.

Once you’ve began to validate that you have a profitable business model, you can start cleaning up and moving towards a 1.0 version of your app that’s built all clean and tidy.

Refine in Top-Down Layers

When we would refactor the Sakani web app, we sometimes focused on relatively small details before taking care of bigger, overarching design problems. It seems comically obvious now that upgrading our web framework—before its team decided to stop releasing security patches for it—wass much more important than getting the right naming conventions in our code. However, when you’re inexperienced and in that adrenaline “fight or flight” mode, you can make mountains out of molehills.

When you refactor, take a whole sprint to do it, and a deep breath before you start. And work top-down, identifying the biggest architectural concerns in the codebase and project. Once those are sorted out, you can move on to the next layer of refinement, until you get to those pesky variable names. What on Earth is $posts3 anyway?

Use Relative Time Estimates & Measure Velocity

Human beings are not great at estimating time. This is something I really struggled with during my time at Sakani. My development team was consistently deliverying sprints later than planned, and I didn’t understand why until I came onto the idea of relative estimation with story points. I will write more about relative estimation in a later article, but the jist of it is that I find that developers are a lot more accurate when the say, “Task A is about twice as complex as Task B,” than when they say, “Task A will take two days.”

So instead of assigning absolute time estimates to deliverable stories, or chunks of work, I’ve found that story points, which are relative weights of complexity, work much better. On one of my current projects we’re using a story point scale of 0, 1, 2, 4, and 8. We then measure how many story points we’ve been completing on average over the last few sprints, and this gives us an idea of our velocity, or speed of delivery per sprint. This makes things much more predictable when you’re managing an agile project, and a tool like Pivotal Tracker can a help a lot with this.


I hope these little lessons have helped you when making development decisions about your app during its early validation phase. I will be writing more about my work with startups and what I’ve learned, so stay tuned.