How We Built a Startup that Produced 5x the Output

We deployed five different product offerings during the same period at less than half the cost of other startups of the same size.

Startups have been in my blood for the past two decades. Most startups failed for various reasons. Not a good product/market fit. Founders were inflexible for pivots. Too many pivots. Mismanagement of funds. Hired too early or built an ineffective core team. All these factors and a combination of others can lead to business closure before establishing a stable revenue stream.

Mistakes will be made along the way, but staying agile and nimble with small and frequent course corrections will allow companies to navigate back to a successful path. With a solid foundation built across the disciplines, handing the keys over to a new owner is redemption of previous failures.

Multiple factors contribute to success but will vary depending on industry and audience and their specific requirements. My focus will be catered around our last SaaS-based business platform and how we managed to get more done in the same period versus other startups.

Vision / Founder(s) / Funding

Ideas are fleeting and not worth the secrecy or paper on which NDAs are written. Ideas without execution fall short of a vision. A vision is what drives founders to risk their time, sweat, tears, and sometimes their money, into a venture.

A solution looking for a problem to solve usually fails to gain traction, whereas identifying and solving for an existing problem has a higher likelihood of pulling in investors for a seed round.

It is possible to raise too much money in any funding round, depending on dilution and projected valuation. You should only raise as much as needed to go to market within 12 to 18 months, with additional rounds following a similar pattern. There is a possibility that an innovative tech-based solution may generate an overabundance of interest with the likelihood of turning away investors.

The visionary founder usually stepped into the CEO or CTO role but wore multiple hats before hiring additional staff and resources. They should look into hiring subject matter veterans as a good foundation for the core team.

The founder(s) should quickly adapt to the tech landscape and welcome risks of emerging technologies which can launch their product to market quicker while being frugal with the funding. They’ll trust the assembled team has the experience and technical merit to transform the vision into a business.

Acceptance of criticism and feedback should balance passion as building blocks toward a stronger base of leadership. A founder should start as an individual contributor to get their hands dirty in the trenches before commanding the troops. Knowing the pain points of each department first-hand is the only way to understand how to fix them.

Our founder had executed on his vision, discovering a problem that plagued most businesses, including the current company he was leading. He decided to carve out some of his time to incubate this idea into something concrete by discussing it with colleagues and shopping around mockups to illustrate his concepts.

He had a voracious appetite for learning quickly, soaking up knowledge from everyone he engaged. With unfamiliar terminology, the next day, he was able to slip it into his sharp cadence of talking points. The context showcased his understanding as if he was the subject matter expert. He had high emotional intelligence and empathy for his colleagues. What he taught me was to identify and promote an individual’s “superpower” while coaching and strengthening their less-flexed muscles.

Working with a founder who can understand the needs of every department, but allowed them to make expert decisions, eased the friction inherent between superiors and subordinates within a traditional corporate structure. It reduced the decision churn and roadblocks, avoiding stalled initiatives.

Mission / Values

For a vision to permeate throughout the company, a mission statement should be written to convey a feeling of solidarity and purpose. Supporting the mission statement should be a set of values that define the qualities governing behaviors critical to the cause.

One of our values that drove high production rates was “Leave your pride/ego at the door.” Regardless of title, tenure, or pedigree, everyone pitched in to get the job done.

We knew building a system from the ground up with modern web technologies would outpace the titans of the human capital market stuck in development molasses.

Fake It / Market Fit

The old cliche used in and around the startup world, “fake it before you make it,” is a practice which allowed early-stage companies to experiment and hone a product. It allowed testing for market fit before a line of code was written. A demo should be built using hi-fidelity or click-thru mockups to garner feedback from friendlies or early-adopter customers. Refinement from test-marketing these early prototypes should be iterated quickly to keep them involved and interested in the process.

The founder(s) should have created a pitch deck or business plan, which includes the problem definition, the solution, value proposition, staff and revenue projections, and ROI strategy. There should be multiple variations of the pitch deck curated to three specific audiences.

The first deck would be catered for investors to convince them to give you money. The second deck would target potential customers to persuade them to buy your product. And the last version would be used to entice future employees to join your company.

Early prototypes were used to sell our vision to sister companies who had similar problems and was searching for a solution. Using the customer-based deck along with mockups returned positive feedback and verbal acknowledgments, exposing an underserved area in the HR space. The anemic area was ripe for a complete solution. Legacy systems, built on old technology, tacked on substandard features simply to tick a checkbox in their offerings.

We knew building a system from the ground up with modern web technologies would outpace the titans of the human capital market stuck in development molasses. This validated our product/market fit and gave us a boost to move forward.

POC / Prototypes

Quick proof of concept (POC) projects and click-thru prototypes set a base for production-ready and user-friendly applications. Having a prototype quickly in front of users helps identify gaps or intices additional suggestions for a tightly-coupled feedback loop.

Fail fast, fail often is also a mantra thrown around startups that should be one of the founding principles woven into the company’s value. Waiting for perfection is a formula that will slow the process; instead, an iterative approach is vital to show progress and perfecting a product.

People / Talent / Structure

A small, focused core group of experienced A-players driven by a determined set of leaders, will out-perform a younger, less experienced team, regardless of their ambition and grit.

A flat structure should be established at first with minimal or no middle managers. A bad hire at an early stage could set back the company months. Multiple bad hires could wreck the company altogether. Establish a quick way to vet and hire candidates with a corresponding willingness to fire them as quickly.

Hiring too early for an idealized corporate structure will cause waste in terms of time, money, and effort. Generalists should be considered for core team members, while specialists can be brought in as needed in later stages.

We had a few missteps in hiring because we wanted to fill positions we thought would move us forward but instead set us back. It was too early. Not only did this cost us stress, money, and time, but it may have interrupted the career paths of those individuals we dismissed.

Vetting for requisite skills and talent overshadowed the need to evaluate a key criterion: the ability to overcome the culture shock of being transplanted from a structured corporate world, with significant support teams, into a startup mentality. We readjusted our hiring strategies to align with shorter-term company goals and accounted for a candidate’s resilience to change.

Our core engineering team of six outstanding members were rockstars who built the foundation and created the initial frameworks based on a progressive trailblazing technology stack. They were prolific coders who left their ego at the office door before coding at their keyboards.

We were able to accomplish feats of astounding progress throughout the years due to our talented server engineer and data architect. During the pioneering days of Node.js, we had to build most mechanisms ourselves. These included an event bus, pub/sub queuing, UI persistence, and caching. All of these homebrewed systems helped us own a unique codebase which can quickly be debugged when an issue was reported.

We were able to hire top engineering talent throughout the years who used their experience to springboard their careers into companies like Google and Amazon. Others branched out to become tech leads or founders of new startups.

As the talent started drying up, we dipped into the code academies’ graduate pool and found great developers looking for an entry into the tech world. This allowed us to enhance the makeup of our diversity. Our engineering team had over 40% of female staff, representing the same percentage company-wide, which was doubled the average in the tech industry.

A stack using the same programming language across all layers with a homogenous transport mechanism sounded like a dream.

Tech Stack / Open Source

Choosing the correct tech stack for building out the solution will affect the production cadence. Being faster to market on innovative features will steer customers to your product, even though larger, more established incumbents exist in the same space.

Some industries will influence the tech stack choice, while others are open to using the latest-and-greatest development language and tools available. The rising popularity of a framework may drive the tech lead’s decision, or it could pivot on the comfort of knowledge towards a specific stack throughout a leader’s career. Rarely does a tech lead deviate from their comfort zone, but those who challenge the status quo may be the one factor that disrupts the space and attracts top talent.

Our choice centered around context switching and fragmentation of languages. It was a conscious effort to reduce both of those factors to increase the speed of development. Even though we would be pioneers using this tech stack, the benefits outweighed the risks. A stack using the same programming language across all layers with a homogenous transport mechanism sounded like a dream.

That dream became a reality when Node.js was introduced to the world. Married to MongoDB, it became the powerhouse which gave us the springboard to outpace our competitors. Adding Google’s Angular.js for a front-end framework was another competitive advantage. Being fully open-sourced was a natural fit towards a lean startup mentality.

The significant advantage gained by using MongoDB was the speed of development. MongoDB is a NoSQL, schemaless storage engine with a rich and robust query language based on the JSON format. Designing a data architecture using documents, without the need for complicated table joins, allowed very fast reads. The mutability of structure added to the quick iteration through design, testing, and release of new features.

With Javascript and the JSON format used across all layers of our application, we transitioned into full-stack developers who were able to cross those boundaries easily. In turn, they shed the cost of context switching and eliminated the dilution of their knowledge with fragmented language concepts.

When we first adopted these new technologies, a Google search for “Node.js” barely returned results. We did not imagine other established companies were on a parallel journey with us, using the same components of this stack. These companies started converting their older platforms to use Node.js within significant systems. Adoption of Node.js by accomplished companies like Netflix, Groupon, Orbitz, Walmart, LinkedIn, Uber, PayPay, and eBay acknowledged our decision was a fit choice. It finally accumulated enough mainstream traction to attain an acronym, coined the MEAN stack.

One former employee adopted our entire tech stack and introduced it as a way to increase their productivity at a major logistics brokerage company. They have built a sizable team around the technology switch and is one of the most innovative companies in their space due to their speed of development.

Today we have continued to promote and use variations of the MEAN stack replacing the front-end framework with React (MERN) or Vue.js (VENoM). It continues to outperform other stacks across multiple criteria: cost of development time, broad community support, increased performance (non-blocking I/O — asynchronous programming), lower memory footprint, lightweight framework, and unparalleled commercial adoption.

Hiring / Onboarding / Training

Most of our early hires were through referrals or known associates. Eventually, our needs grew enough to hire an internal recruiter to churn through hundreds of resumes a week. When a noteworthy candidate was identified, we sent out a small code challenge to further weed out the weaker candidates or imposters.

If a solution to the challenge was returned, it was graded based on several criteria which indicated their level of experience. The candidate is then invited to an in-person office interview, where they will meet other team members and participate in a mock code review of their solution. This will further ferret out candidates if they cannot clearly articulate their thinking process while answering code-review questions.

If the candidate receives a positive consensus, an offer may be extended on the same day, moving them forward to the onboarding process.

Having a defined and quick onboarding process helps with productivity. The goal is to have a new hire up and running by the end of their first day. For engineering staff, they are assigned an onboarding buddy (who happens to be the last hire through the process).

New developers then joined a training team and assigned their first project, which is usually a low-level defect or smallish project. We called this training group, the Strike Team. Their goal, within the first week, should be a submission of their first pull request (PR). Also included should be scheduled 20-minute discussions with each of the engineering leads, product group, and other department heads. Any follow-up discussions should clear remaining questions about the team roles, responsibilities, code-base, and development process.

New hires are also allowed to be recruited by squad/guild leaders for exposure into their realm. By the time they graduate from the Strike Team, they will have an idea of which squad/guild they’d like to join. These guilds included: UI, Server, Data, Mobile, Integrations, QA, and Strike.

Infrastructure / IaaS / PaaS

Going to market fast can’t wait for an infrastructure to be built. Setting up servers, routers, phones, redundancy, security, business continuity (BC), and disaster recovery (DR) requires a substantial amount of resources and time. Reducing or eliminating the use of on-premise equipment refocuses all the efforts of an engineering team towards coding solutions instead of tinkering around with hardware setup.

Moving to a cloud-based infrastructure using combinations of services like Amazon AWS (infrastructure as a service — IaaS) and Heroku (platform as a service — PaaS) eliminated the need of an internal dedicated DevOps member. Both of these services have robust APIs, which allows developing scripts for quick setup, maintenance, deployment, and scaling through an automated process.

A lean startup could not house a big enough DevOps team to match the 24/7 capabilities of entire organizations dedicated to the maintenance, backup, redundancy, disaster recovery, security, and business continuity of your infrastructure. Using an IaaS or PaaS vendor gives you an entire DevOps team at hand to leverage their expertise in what they do best.

Plan an infrastructure for a worst-case scenario where the office has no power or possibly destroyed through fire or natural disasters. The SaaS platform should continue to hum along even if your headquarters have internet issues or leveled by a Category 5 hurricane.

We leveraged AWS S3, AWS CloudFront, AWS CloudTrail, AWS Lambda, and Heroku. Our MongoDB instance was also hosted on cloud-based services. We did not use Docker or Kubernetes because Heroku handled it through building out slugs (Heroku’s version of containers) and supported pipelining between environments. We were able to scale, release, and promote features through simple UI controls.

QA / QC

Once a product hits the Beta milestone, unit-tests will not cover edge cases observed in the wild. A dedicated QA lead and team should be brought in to help ferret out defects. A good ratio of QA staff to developers is three developers to every one QA tech.

As the product grows, automated end-to-end testing should be added. A QA tech should lead the effort, recruiting developers to help write automated tests along with unit tests.

Leverage QA skill to help fix minor defects they find, by setting up QA machines as if they were developers. Train QA members to fix mistakes like typos, language files, and small CSS issues. Have them check those fixes into specific feature branches. This may have the added benefit of defining a career path for a QA tech to move from testing to development.

Let QA dictate the release cadence by allowing them to deploy and promote features. Isolate those feature branches into separate test servers before they are merged and deployed to an integration server. Since QA controlled the last gateway before the code went into production, it was logical to allow them to sign off and merge those feature.

We had multiple testing environments for QA to deploy features in isolation, which allowed them to target only the changed code. Environments for each guild type were also available for teams to deploy and test in a simulated live environment versus locally on their development machines. Exposing the feature opened it for stakeholders to access, verify, and validate it was working as designed.

Our QA leader increased coverage of tests by hiring an out-source company in India to augment our testing. She led an effort to set up a deployment server, allowing the remote QA team to deploy feature branches and test during off-business hours. This doubled the testing coverage across all of our products.

No precedence or articles existed described such a process. Internally we dubbed it zero iteration based development.

Process / Planning / Release

An established software development life cycle (SDLC) and the process around planning defines the cadence of releases to end-users. The agility to alter this cycle and flatten out roadmap speed bumps will increase the velocity of developed and released features.

Releasing features more frequently exposed issues earlier for real-world use and feedback, tightening the iteration loop, and allowing us to polish the product quickly. Development teams were able to push new releases as fast as they were coded, until paying customers started using the platform.

We organically grew into a weekly release cycle, intentionally not aligning with development sprints. QA would control the releases, in coordination with Product and Customer Success teams. QA being able to deploy, merge, and promote features allowed full control of the release cycle, including major, minor, and hot-fix releases. QA worked in a Kanban fashion, where features were cued up and dropped into the release when ready.

Development spans were usually planned into 2-week sprints, with larger projects spread across multiple phases. Deployments were scheduled weekly for Thursdays, during the day, with 100% uptime using the pre-boot feature afforded to us by Heroku. Sprint grooming, planning, and retroactive sessions were held on Friday mornings.

Eventually, when we documented our process, it did not match a traditional agile pattern but was based on time slice iterations. A feature being currently developed would represent the present time slice (T Zero). Developers would be working on the zero iteration. QA would be testing T-1 features, one iteration behind the development team. These were coded and approved pull requests (PR) waiting in a queue.

The Product team would be working on defining and writing specifications for T+1 features, one iteration ahead of development. Designers created mockups and wireframes two iterations ahead of development, working on the T+2 slice. Customer Success and Marketing would work in the T-2 slice, which was features tested and released by QA. Sales worked in two different slices: T+2 and T-2 slices. Sales had to market new upcoming features and promote already existing features.

T-2: Customer Success, Marketing, Sales
T-1: QA, UAT
T Zero: Research, Development
T+1: Product
T+2: Design, Sales

No precedence or articles existed described such a process. Internally we dubbed it zero iteration based development.

Multiple features across a few different squads were being developed in parallel. At any time, there could be five or six projects being engineered at once, one for each squad. When a larger initiative was launched, members of specific squads broke off from their group, swarmed into one large team, and pounded on their keyboards until completion. Once developed, they disbanded and returned to their respective squads.

At one point in our journey, developers were extremely prolific in their coding, which resulted in over 80 pull requests (PRs) slated for testing and deployment. We had to slow down and shifted our attention on helping QA test, merge, and deploy those features out to production. After our QA swarm, we were back down to our typical set of five to ten PRs in the queue.

Product Design / UX

Initial product design and management responsibilities landed on the founders, but eventually, the product grows big enough to demand a full-time product manager. The first product manager (PM) is a crucial hire to be added to the core team. They will evolve into a director of product and lead a team of their own.

The PM should have the ability to take on raw visionary concepts and convert them into wireframes and stories while incorporating their ideas smoothly along with a sense of design. During the early stage of a startup, PMs should seamlessly interact with almost every department in the company, switching hats effortlessly through the same stream of consciousness.

User interaction (UX) and UI design tasks also fell into the PM bucket, until the abundance of planned features starts to spill over. At this juncture, a UX lead should be hired to standardize the design across all products. A consistent look-and-feel and design language spanning the product offerings helped users transition smoothly across applications while flattening any steep learning curves.

Well defined stories and specifications drive efficiencies in development, testing, documentation, and validation by creating a blueprint of reference across all departments. When using the specs as an established reference, a feature moving from concept, through production, release, training, and support rarely gets snagged in a fast-paced assembly line.

Through a sister company, we had a successful introduction to a talented PM who we convinced to start with us, turning down an out-of-state job offer. It was a mutual risk on both sides, which resulted in an incredible hire.

Mobile App

A mobile application or mobile-friendly website helps engage users that are not tied to their desks. Targeting those organizations that are geographically dispersed with an easy interface providing the essential functions of your product is key to high engagement.

We planned to build a mobile app from inception and deployed to both iOS and Android platforms early in our roadmap. Using the same web technologies with a native wrapper allowed us to produce, update, and extend our mobile offering quickly to our users.

A major selling point to our platform was due to the tight parity between our mobile and web apps. With a dedicated internal squad working on mobile, we were way ahead of our competition, while other startups outsourced their mobile production.

Meetings / Standups

During the early stages, a majority of the day was spent in meetings, but as things fleshed out, they subsided. Weekly status meetings held steady, while operational meetings were called as needed.

Bringing Slack into our communications toolbox reduced email churn and eliminated some one-on-one meetings. Most meetings were reduced down to three major concerns: roadblocks, announcements/decisions affecting the participants/company, and show-and-tell. The exceptions were sprint planning, grooming, kickoffs, and retrospectives, which had standard concrete agendas.

Development standups were scheduled daily, 10:30 in the morning, as needed, and should last five to ten minutes. Each squad/guild can run them as they desired with specific agendas, as long as it moves the process forward. A weekly Scrum of Scrums (SOS) was held for significant announcements, shared by each squad/guild to sync on current projects or team building events.

In the end, it propelled us to the top of our space, caused us to grow at a faster pace as we produced our best work in a frenetic sprint of focused passion.

Pivots

When the initial execution of the business does not gain the expected traction, then it’s time to explore the possibility of a pivot. This change may include a reduction in staff, a refocus on a niche audience versus broad-spectrum, or, concentrating on specific types of campaigns.

One of the most successful pivots that have been publicized is how Groupon pivoted from a group activist site to a group purchasing site. Groupon started as a site called “The Point.” It promoted social activist campaigns that had required a specific number of users to sign on until it reached the tipping point for action. In 2008, one of the most famous and outrageous campaigns was to suggest building a dome over Chicago to control the weather, for a mere price of $10 billion. It had pledges of over $100,000 in a few days, but it never reached its tipping point.

The most popular campaigns that The Point promoted where group purchasing campaigns, where it would solicit bargain pricing from local retailers if it garnered enough pledges from users. The rest is history as they changed their name to Groupon, concentrated on discounts purchasing deals, and dominated the market.

Our pivot wasn’t quite as dramatic but organically grew from demand in the market place. Our vision was to cater to an underserved niche in the HR space, where SMBs were neglected. The projected revenue growth in this space gave us our hockey stick graph, but reality did not meet theory or the might of will. The amount of time and effort required to land an SMB account was about the same for Enterprise customers, but with an almost 10 to 20 times return on investment.

This switch affected all departments, but pushed us in the right direction, and forced us to optimize and scale to support a more extensive customer base. We had a staff reduction in the sales department but increased members of the engineering team. Moving from serving 5000-employee SMBs to 100,000-employee enterprises was a shift that taxed us mentally, financially, and physically. Weekend work was the norm until we launched our first enterprise account.

In the end, it propelled us to the top of our space, caused us to grow at a faster pace as we produced our best work in a frenetic sprint of focused passion.

Acquisition / Lather, Rinse and Repeat

If a startup has a foothold in their market and sticks out as a leader in the space, then suitors will be looking to acquire you. We were acquired by a private equity firm which had the resources that can move us to the next level of our growth.

There were many other factors involved with our successful acquisition, but the ones outlined were the most influential, producing the most results in a short span.

These factors interacted and comingled to produce a perfect storm of rapid growth, leading to a successful exit. We were the same size as other startups but were able to deploy five different product offerings during the same period at less than half the operating cost.

The excitement of building something out of an idea is why I continue to stay under the startup umbrella. The combination of talent, process, grit, determination, and the prospect of opportunity and learning pushed us to strive for success that others took for granted. The early days were filled with doubt and the unknown, encouraging a small group of passionate founding members to sacrifice every ounce of energy towards a shared goal.

We became a second family that celebrated the wins and bore the losses; lessons learned to be used as tinder for the next endeavor.

Charles Rapulu Udoh

Charles Rapulu Udoh is a Lagos-based Lawyer with special focus on Business Law, Intellectual Property Rights, Entertainment and Technology Law. He is also an award-winning writer. Working for notable organizations so far has exposed him to some of industry best practices in business, finance strategies, law, dispute resolution, and data analytics both in Nigeria and across the world

Tags: Startup lessons, STARTUPS

Afrikan Heroes