In this chapter, I share a story about when your organization successfully launched its very first version of the product and started gaining revenue and customers. At that stage, your team consisted of around 4-8 engineers. Here, the story begins: the challenges arise not only in Engineering but also within the organization itself.
The first one is about prioritization: Your team's purpose is building product development and establishing market presence. Sometimes, You feel unclear direction, build features here and there. First, As a Funding Engineer assesses the urgency and impact of the feature request. Ask the questions like:
- Is this feature critical for a key business initiative?
- Does it have a significant impact on customer satisfaction or revenue?
- Are there deadlines tied to marketing campaigns or external commitments?
- … etc
Here’s an example of the situation:
Your stakeholder is asking to build a coupon feature with specific rules because next week the marketing team will be expanding to another city. You only have one week to build and deploy this feature. The first thing you need to do is cut any functional requirements that do not directly impact your users, such as building internal tools for managing the coupons (CRUD operations). Instead, offer a solution where engineers and product managers can create coupons in the system using an API or by editing the database directly. With this solution, your stakeholder will still achieve the goal of expanding to another city and capturing momentum by offering incentives through coupuns.
| Use Case | Implementation Details | Priority |
|---|---|---|
| As a User, I can apply a coupon in Consumer Web | Frontend Web UI, Backend API | P0 |
| As an Internal User, I can create/update coupons from the internal web | Internal Tools UI, Backend API | P1 |
… from this example, It is of key importance to balance between “now” & “next” problems.
Now
“You achieve the immediate business goal, our customer can apply coupon from our applications”
Next
“This approach is not scalable and can lead to inefficiencies and potential errors over time as the manual process is prone to mistakes and is not user-friendly for non-technical staff.”
Sometimes, as founding engineers, you need to make some changes to less-than-ideal code (anti-pattern) to support your business. I have experienced this, when I had to hardcode logic in the frontend to automatically apply a free delivery coupon when users checkout if the traffic came from a specific campaign or partnership. Our frontend logic was something like this:
When a user visited "yoursite.com?utm_campaign=partner_ecommerce", I identified the utm_campaign parameter and then applied a small piece of logic to automatically apply the coupon. At that time, I needed only one day to make these small changes and deploy to production.
“Now” and “Next” problems, looks like:
Now
“We can measure the impact quickly with minimal time to ship to production.”
Next
- Technical Debt: This kind of hardcoding can lead to accumulating technical debt, making future changes and maintenance more difficult.
- Scalability Issues: Such a solution is not scalable and can become problematic as the number of campaigns and partnerships grows.
Balancing these “Now” and “Next” is crucial in a startup environment. While quick and dirty solutions can provide immediate business benefits. After get the outcome, engineering can plan proper or scalable solutions balanced with time and impact.
Here is the complete playground:
More focus on “now” problem, every startup has limited "timebox"
But, it's not only about business. As founding engineers, you need to plan your infrastructure, process and culture. Here is a bare minimum list that your team needs to have:
- You have clear software methodology, SCRUM is preferable (daily standup, sprint planning etc). Like or not business teams always ask “are we productive enough” ?. Need clear and same understanding about capacity planning.
- Invest in CI/CD, at least you don't need to “ssh server” then deploy your changes, use jenkins. Try to automate repetitive tasks!!
- Code quality, you don't need microservice to make your system scalable. At least your code is testable (Unit test). It would be great if you have a culture of writing tests first before code.
- Invest in Monitoring tools: newrelic (free tier), firebase analytic and crashlytics sufficient to monitor your end to end system.
I do not believe in “Roadmapping”. You are not a feature factory, focus on outcome rather than output.
Yeah, I understand that as an engineer, I want to launch a product with a scalable system, but simplicity is the key ingredient. Let your team repeat the above process for several months. If your technical debt or monolithic system becomes unscalable due to team and business growth, the system will become a bottleneck, making it harder to ship features and hindering organizational growth. This can be one of the most frustrating moments as a founding engineer. I will explain more in the next chapter.