Building MVPs with K-Optional - The Pipeline

Have an idea for a platform? Building a robust MVP is the first step. This can be very challenging for many reasons. Particularly:
  • The bureaucracy of large software companies is almost always overkill. Plus they'll charge you a fortune and will be generally poor at prioritizing features for launch.
  • Smaller development teams and freelance developers often lack transparency and accountability; we've had many clients at K-Optional who had experienced a slow and painful failure with a previous developer / development team. This includes
    • Failing to meet deadlines by months
    • Lack of communication
    • The disappearing act
  • Knowing how to build an MVP is a wisdom achieved only by experience. Even if someone is a competent developer, they have no chance of owning your first´ version if they haven't run projects like it before.
Through dozens of minimum viable products, K-Optional Software has mastered the craft. We know the things that tend to pop out at you during the process, and how to handle them. We've distilled our experiences into a robust pipeline optimized for helping you launch your vision in a timely manner.

I. Narrowing the verbiage gap

If your development team doesn’t insist on communicating extensively about your vision, the rest of the process will be excruciating. That’s not to say you can’t iterate, pivot, or augment the application as you grow. But you won’t get anywhere if development doesn’t understand the way you’re thinking.

There are two primary types of information that must be exchanged pertaining to an MVP.

Domain specific information represents an understanding of how an industry works. For our Gridworks Platform, K-Optional had to invest heavily in understanding the cabinet manufacturing industry. Specifically, our software devs had to wrap their heads around terminology like “buy-outs” and “carcasses”, as well as the typical process for how cabinets were sold (builders tend to buy cabinets for the owner of the house, and they work in conjunction with architects and designers etc). In general, we follow the principles of Domain Driven Development which revolutionized the importance of development teams comprehending the domain they’re modeling.

Additionally, developers must have a complete sense of your venture. This includes the general value proposition of the idea, as well as its core features.  Explaining your vision forces you to decide on the important components; only after a comprehensive dialog will the team be able to assess tradeoffs for different features (in terms of time / money vs value). Being transparent in this way allows you to prioritize effectively. The unfortunate inclination is for a founder to merely explain the gist of their idea before development begins. Spending 50% of development resources on an unnecessary feature is a common outcome.

II. Formalizing the development process

After getting on the same page with development, everyone must be explicit about what’s being built. K-Optional provides a document that describes exactly what features we are developing, with some sort of timeline for milestones. We also agree on a process for communicating what we’re working on and what needs to be done. This is less for each party to cover their ass, and more to serve as a foundation for the project. In our experience & observations, chaos almost always ensues when this step is not taken seriously. This includes missed deadlines and poor communication.

III. Mockups and Prototypes

K-Optional understands the importance of User Experience, hence we follow best practices when developing interfaces. Importantly, we approach design in a lean manner. We’ve found that prototyping directly in HTML / CSS is more efficient than beginning with a design tool like Photoshop or Illustrator. For one thing, you end up redoing work (creating in two different mediums requires nearly twice the work) which hinders an MVP. Additionally, somethings can’t be effectively replicated outside of a web browser- responsiveness, animations, and user inputs are all very difficult to represent elsewhere.

There are plenty of other advantages to working in markup out of the gates. When we begin a project, we provision an Amazon S3 (free for all intents and purposes) that is continually in sync with our code. That way our clients can follow along with our design implementation and provide us with realtime feedback.  We begin the next phase only when everyone is happy with the look and feel, so the outcome is the same as if we used a design tool. That said, we’ve also had clients provide us .psd files in the past which we then implemented in HTML.

IV. Technological Decisions & Development

This phase covers all functionality and business logic. It is usually significantly more time consuming than the other stages in the pipeline. We break this step up into 3 sub-steps:

1.) Solution Design

The more experienced a developer is, the more time he will spend solving a problem on paper prior to writing code.  As the saying goes, there is more than one way to skin a cat.  Our job is to determine the most effective way with respect to robustness and resources.  K-Optional breaks down the application to a number of subproblems, and then applies the most relevant software design pattern to each part. If no pattern applies, we break down the problem further. Hence we are proud to be well versed in (and up to date with) the software patterns literature. Our favorites are Pattern-Oriented Software Architecture and  Design Patterns: Elements of Reusable Object-Oriented Software.

If you are somewhat technical, this is also where we pick a framework such as React or Laravel. You can checkout our case studies to see the breadth of our familiarity with different technology stacks.

2.) Solution Implementation

Actual implementation is just letting gravity do its work. We write clean code and send constant updates to our clients with the newest version.

3.) Quality Assurance

Those familiar with the process know how underrated QA is. We write many different types of tests, and generally systematize making sure things work as expected. That way updates and fixes are a breeze.

V. Deployment & Iteration

The most rewarding part for our clients is launch. But we still have work to do; We consider deploying an application to be a trade in and of itself. The K-Optional team exemplifies DevOps, meaning that we excel at both development and things like continuous integration. We are masters of the cloud (usually utilizing AWS or sometimes Google Cloud), and make sure your platform scales seamlessly. We’ve saved our clients a lot of money through optimizing cloud services.

After launch, you can keep us on to further refine and augment your product. K-Optional will integrate your app with analytics and search engine optimization so you can make the most informed decisions on how to grow your company.

Final Notes

The K-Optional Pipeline is agnostic of communication tools, development methodologies, and project management software. We typically use Slack and email, and employ agile software development. Additionally, we usually use Trello, Jira, and/or Github for task management & issue tracking. Most importantly though, we can adopt any system that you prefer.

We’ve designed the K-Optional Pipeline with transparency and reliability in mind. Feel free to ping developer@koptional.com if you want to talk to any of our clients about their experience.