Case Study: Milkbasket
Context
In early 2017, I joined Milkbasket as an advisor to the CTO during a period of early growth.
The product had already launched and demand was increasing. Much of the engineering work, however, had been delivered through external vendors rather than an internal engineering team.
This approach had helped the company ship the first version of the product quickly, but the structure was beginning to show limitations as the product and organization grew.
Friction
Several structural issues were beginning to slow the organization's ability to evolve the product.
Engineering Ownership
At the time, the company did not yet have an internal engineering team responsible for the product.
Much of the implementation knowledge lived with external vendors. While this enabled early delivery, it limited the company's ability to independently evolve the platform.
Vendor-Driven Development
External vendors played a central role in product development.
However, product requirements and specifications were not always structured clearly enough to ensure consistent delivery. This created ambiguity in feature implementation and increased coordination overhead.
Product Development Practices
Product development practices were still evolving.
Requirements documentation, feature specifications, and development workflows were often informal. As the product grew, the lack of shared documentation and structured planning began to introduce friction between product managers, engineers, and vendors.
Architecture Evolution
The initial product had been built quickly to support launch.
As new capabilities were added, the system architecture needed clearer direction to support continued expansion and maintainability.
Intervention
The reset focused on introducing structure across three areas.
Objective 1 — Establish internal engineering ownership
The first priority was building an internal engineering core capable of owning the platform.
Working with HR, we developed a hiring framework that defined role expectations, evaluation processes, and job descriptions.
Rather than scaling quickly with junior hires, the initial focus was technical leadership.
The first internal hires included:
- a development lead
- a QA lead
These leaders would later build and manage their own teams.
Within roughly a year, the company grew from no internal engineers to a team of more than ten, establishing internal ownership of the platform.
Objective 2 — Stabilize vendor collaboration
Milkbasket had already invested significantly in external development partners.
Instead of replacing them immediately, the focus was on improving the collaboration model between vendors and the product organization.
The main change involved introducing clearer product specifications and acceptance criteria, reducing ambiguity in feature delivery.
This allowed internal engineering leadership to coordinate work more effectively while vendors continued contributing development capacity.
Objective 3 — Reset product development practices
As the internal team grew, the next step was strengthening the product development process.
Several practices were introduced:
- a shared documentation repository
- structured requirement gathering
- evolving specification templates
These practices created a common language between product managers, engineers, and vendors.
The team also began adopting shorter development cycles and iterative delivery, enabling faster feedback and more continuous product improvement.
Structural Changes
By the end of the engagement, Milkbasket had begun transitioning from vendor-driven development to an internally owned product platform.
Several structural capabilities had been established:
- an internal engineering team with technical leadership
- improved collaboration frameworks with external vendors
- shared product documentation and specification practices
- early adoption of iterative development workflows
At the same time, the organization began exploring a gradual architectural evolution from a monolithic system toward a more modular service-oriented architecture.
Outcomes
These changes allowed the company to expand the product platform with new capabilities, including:
- coupon and invite code systems
- product bundles
- internal operations tools
- improved search and recommendation features
More importantly, the engineering organization moved from reactive feature development toward a more sustainable model of product evolution.
The company now had the internal engineering capability needed to continue expanding the platform as the business grew.