Building an Application From Scratch and What We Have Learned From It
Nine months ago, we finalized our product strategy. In October, we completed our Alpha release, a step closer to beginning user acceptance. All great experiences. New frameworks, new techniques, unforeseen challenges and the excitement to scale up the development team.
As many tech startups need to build their application from scratch, it has been an amazing experience so far. I’d like to share the lessons we’ve learned during this phase.
Building an Application From Scratch
Before we dive into the lessons we’ve learned, let’s start by quickly sharing why we have decided to build — because after all, we are building without a shortage of ambition.
When Jason, Martin, Chris and I founded Kambr, it was clear that our goal of trying to advance commercial aviation would have a greater chance of succeeding if we bundled our strengths and built Kambr on three business entities: media, advisory and software solutions. For me it was the perfect opportunity to build a software solution which supported the concept of total airline commercial aviation. With our backgrounds as builders and users of commercial aviation software, we have the added advantage of knowing exactly what our product should do and how it should be used. Combined with a solid development team, we rolled up our sleeves and started building in April this year…
At the beginning, we knew our strength could also be our weakness. Given our decades of domain expertise we knew exactly how the final product should look and function. We easily defined a solution including product vision, mockups and a solid data architecture to run it on.
The thing we underestimated was the broad scope of the solution, we needed to narrow the focus and build the foundation first. Practical user functionality, data visualization tools and machine learning. All great, but where to start?
In other words: we had a clear vision, we had a solid engineering plan and no shortage of great ideas on what the product should be doing for the user: descriptive, diagnostical and predictive features, voice-enabled engagement, etc. The question was, how to translate that into a solid development plan?
Lesson 1: Try to Avoid Any Assumptions
Who doesn’t want to build applications using the latest design principles and incorporating the flashiest features with the goal of delighting their customers? We all do. We were excited to share our vision and plans for the final product. Thankfully, by help of our Product Owner, I realized I needed to focus on the details before moving on to the big picture. This was not an easy shift as I had spent months, talking with investors and potential customers and selling them the grand vision. Now I was sitting with a development team who needed to understand how the bolt should work so they could build the machine.
Let’s use the example of building a theatre. When building a theatre, your investors are mostly interested in the pain you’re solving by building the theatre, how your theatre will be better than the one down the road, how much money it will make and how you plan to scale. The customers are mostly interested in its convenience, look and feel and figuring out whether it’s better than the one down the road. In those discussions nobody cares about the light fixtures, location of the emergency exits or the brand of lavatories you plan to install — the building hosting your theater. Developers can be mismanaged if you immediately demand them to build the stage and effects. Sooner or later you must mention that your stage needs to come into a building, and the building needs to come with a large amount of basic facilities. Not looking at these facilities may cause you to stop the performances, something you want to avoid at all cost once you are open for business.
Especially in the beginning where everybody is occupied with a concept called the Minimum Viable Product (MVP), it is crucial to also discuss as much assumptions which come to mind. If not, simple things can be easily be forgotten. For example, while it has nothing to do with the stage and performance, who has ever been in a theater without a restroom? In development terms such a facility is called a delighter, and that is totally true. But the more you know in advance, simply bring it up.
The better you can share your assumptions, the better you can set your focus. Your Product Owner is the best person to understand the relevancy of your input, so just throw them out. He or she will love you for it (in the long run).
Lesson 2: Separate Rules From Exceptions
Like many other industries, the domain of commercial aviation is quite complex to understand as an outsider. Scaling up a development team with limited domain expertise is therefore quite a challenge. In sharing your knowledge, which you have gathered over the decades of working experience, you try to simplify things as much as possible. Like learning grammar of a foreign language, there are rules and exceptions.
Best option will be to recruit developers who have knowledge in the domain. But we also know how difficult it is to find them. When hiring outsiders, you want to make them productive as soon as possible so nobody wants to send new recruits to a course for months before they can use them to build your solutions.
I have struggled mostly with the vocabulary differences between rules and exceptions. Be keen to convey the differences between a rule from an exception. With the overwhelming stream of information, you need to extra highlight those differences as they define the complexity of your engineering framework. Push hard on items which are rules, where we need to life by. Leave out exceptions which generally cause confusion and can be handled at a later stage.
Luckily, I am not the only person with the domain expertise. I realize how valuable it is to be able to lean on my co-founders and other domain experienced employees who can share their knowledge with our team members who just got exposed to the magical world called ‘aviation’.
Lesson 3: Understand When to Pick Quality Over Quantity
The third lesson is maybe the most valuable lesson I’ve learned over my career. I take pride that our development team is hyper-focused in this process and therefore actively participates in discussions to find a perfect balance between quality and quantity. In the effort to ‘wow’ your customer, you may risk that you build a large amount of ‘almost-done’ features, or contrary, aim to build the perfect single feature.
The state of ‘feature ready’ is something many organizations struggle with. The reality is that in technology features are never ready. But you reached an important milestone if you know it works for all your customers. I call it product-market fit — a process in which we seek for the optimal balance between market acceptance and product perfection.
This logic sounds very simple, but the truth is a largely undefined area between an attempt to build fast and deploy versus having every single scenario covered and tested in high-quality code. I have noticed that we really strived to build a broad set of features to showcase all favors of our solution. Alpha was our first attempt to translate our product vision into the application itself; the first step from product prototypes into a solutions framework. Now, we are setting ourselves up for the next step; Beta release. Wherein we pencil in all the required functions in the framework with the goal to have our customers use the features.
I cannot wait for this release to be complete. A lot of work needs to be done but one thing is for sure: new challenges will arise.
