Prithvish Rakesh Doshi has built his career on solving complex engineering problems with both breadth and depth. With a foundation in data structures and algorithms and hands-on experience developing scalable backend systems in Java and Python, he has worked across industries from healthtech to fintech, and now serves as a software developer at Kaizen Software Systems Inc., where clients include Fox, Deloitte, and Convera.
Having navigated both the speed-driven world of startups and the process-heavy environments of mature companies, Prithvish brings a unique perspective on what it takes to ship fast without breaking things, balance scalability with sanity, and think like a founder while writing code. In this conversation with Alltech Magazine, he shares lessons from building products at different stages, frameworks for making tough technical decisions, and the habits that help engineers thrive in high-stakes environments.
In your experience, how does engineering at the earliest stage of a startup differ from building products in a mature company?
Early-stage startup engineering is focused more on building and iterating quickly. The mindset shift between startups and mature companies boils down to this: survival versus sustainability. The 80:20 rule applies.
If non-critical flows are mostly working, it’s better to ship and keep improving rather than wait for perfection. Requirements are dynamic, and customer issues need to be addressed at the highest priority. As an engineer, you wear multiple hats: backend, frontend, functional testing, deployment, cloud infrastructure, and even some business-facing discussions to understand customer pain points. A one-line summary would be: ship as fast as possible, and try not to break things.
Engineering in a mature company, on the other hand, is all about resiliency, robustness, and adherence to processes. I’ve worked in both healthtech and fintech at larger companies, and the stakes are very different. Because the impact of even a single line of code can be massive, you don’t have the same liberty to just “try things out.” Every feature requires deep consideration of edge cases, multiple levels of review, and rigorous testing across specialized teams before release. The focus shifts from speed to reliability, compliance, and long-term maintainability.
In short, startups teach you breadth: how to move fast, adapt, and solve problems across the stack, while mature companies teach you depth, showing the importance of precision, scalability, and building systems that last.
Why is it important for early-stage engineers to think like PMs and founders rather than focusing solely on writing code?
Early-stage engineers are not just engineers. Because they juggle multiple types of tasks on their plate, it’s critical to keep the bigger picture in mind. At a mature company, a one-day task might be something narrow, like implementing an API endpoint to handle a specific request, where the product requirements are already finalized and well-documented.
For an early-stage engineer, however, the scope is often much broader. For example, instead of just writing an endpoint, you might need to design the entire flow for onboarding new users: choosing the database schema, setting up authentication, building the frontend form, handling edge cases in backend logic, and deploying it to production, all while ensuring the UX is simple enough for customers to adopt quickly.
In such cases, you can’t just “write the code” in isolation. You have to think like a PM by understanding the user journey, prioritizing which features are critical for launch, and making trade-offs between speed and robustness. Only then can you switch into pure engineering mode to implement the solution.
Can you walk us through the “tradeoff triangle” of speed, scalability, and sanity, and how you decide which two to prioritize at different stages?
From my perspective, the right priorities in the tradeoff triangle depend on the company’s stage and goals. In the early stages, I believe speed and scalability are most important. You need to move fast to deliver features and capture users, while also ensuring the system won’t completely collapse if adoption spikes. To balance the sanity side, we scheduled a dedicated one-week sprint every 4-6 weeks (or during slower periods). That sprint focused on cleaning up tech debt, like covering edge cases, addressing deferred requirements, and refactoring code for maintainability.
My general framework for deciding which two to prioritize is based on the impact of change vs. user growth.
- If the main driver is rapid user growth, I lean toward speed + scalability, even if it means the codebase gets a bit messy.
- If we’ve reached a stage where each feature or bug fix has high user impact, I shift toward scalability + sanity, making sure the system is both robust and sustainable for the long term.
What’s your approach to building a version one product that has just enough friction to test whether there’s real demand?
My approach to testing the v1 (or rather v0 :p) of a product is built around this ideology: the most promising core use case plus three supplemental features. For example, if I’m building a mobile application for P2P transactions, my v0 would focus on the core functionality, i.e., sending money from one account to another. Around that, I’d add three basic but essential features such as:
- Viewing transaction history.
- Adding and managing contacts.
- Basic notifications or alerts for successful transfers.
With this minimal version, I’d start by reaching out to friends and family for feedback and iteration. (This works well for consumer products; for B2B companies, the approach would be different – usually starting with pilot customers or design partners.) Once the MVP feels polished enough, I’d launch it to a broader audience and measure traction to validate whether there’s real demand.
How do you balance building quickly with avoiding technical debt that could slow you down later?
Like I mentioned earlier, one effective way to balance speed with technical debt is by scheduling regular clean-up sprints. These give the team room to refactor code, cover edge cases, and resolve deferred issues without slowing down day-to-day product development.
Another idea, though I haven’t implemented it yet, would be to leverage AI agents to actively monitor the codebase. For example, an agent could scan the repository at the end of each week to flag duplicate code, highlight obvious optimizations, and generate a suggestion report. This would help the team understand when cleanup is critical and how to prioritize it. And why stop there? An AI agent could also generate production-quality documentation, further reducing friction for engineers and making the system more maintainable in the long run.
Which tools, processes, or frameworks proved most valuable in taking a company from an idea to a functioning product?
On the technical side, some tools and frameworks that proved most valuable include Git for version control, SST for managing cloud infrastructure, and CI/CD pipelines to ensure basic robustness of product features. Tools like these take a huge mental load off the team, allowing us to focus on building and iterating quickly. If something goes wrong, we can easily revert to a previous working version, minimizing impact on customers.
On the process side, I found that weekly product reviews with the whole company helped everyone understand where we stood, while a lightweight agile methodology allowed for efficient sprint planning and prioritization. Constant interaction with customers also ensured we were learning what was working and what needed adjustment.
Finally, mental frameworks like the 80:20 rule and the build-measure-learn loop were critical for decision-making and prioritization. They helped us focus on what would deliver the most value quickly while validating assumptions before investing heavily in features.
What mental models help you make high-stakes technical and product decisions when information is still limited?
Here are some mental models I’ve used that have proven helpful in high-stakes decisions.
First Principles Thinking is one I rely on heavily. This means detaching from assumptions and technical details and focusing on understanding the problem from the ground up. For example, if I’m building a payment system, I start with the fundamental need: users must be able to send money from one account to another, and then build up from there.
Opportunity Cost Evaluation is another key framework. What am I losing on, if I take path A vs path B. That helps with aligning a decision directly to what it costs me, and makes prioritization easier.
Finally, stress testing with “What If” scenarios is crucial. I mentally simulate reasonable worst-case outcomes to ensure the product and system can handle unexpected challenges, whether it’s traffic spikes, edge-case transactions, or failure in a dependent service.
Looking back, what’s one thing you would have done differently in the earliest build phase, and what lesson can other startup engineers take from that?
Looking back, one thing I would have done differently in the earliest build phase is to put some basic processes in place earlier. In the rush to ship features, it’s easy to skip things like CI/CD pipelines, automated test suites, or lightweight code reviews, but even small investments there can make a huge difference in developer experience and speed down the line. I also wish we had introduced feature flags from day one. That would have allowed us to ship quickly while controlling risk and iterating safely on new functionality. And finally, I would have spent just a bit more time thinking about architecture, not just features, making sure the system was modular and flexible enough to evolve without major rewrites.
The key lesson here is that these small investments don’t slow you down; they make iterating faster, safer, and less stressful as the product grows.
If you could give one piece of advice to an engineer about to join a startup on day zero, what would it be and why?
Embrace the chaos. Day zero at a startup is a masterclass in resourcefulness—you’ll learn faster here than anywhere else. But remember: small investments in processes (CI/CD, feature flags) pay exponential dividends later. Think like a founder, but code like an engineer who’ll inherit your tech debt.
The learning opportunities are endless, and you can grow as fast as the company does. Approaching problems from a top-down perspective, understanding the big picture before diving into details, can save a significant amount of time and help you make better decisions. For example, before writing a single line of code, take a few minutes to map out the user flow or system design; it often uncovers edge cases or simpler solutions that save hours later. Holistically, stay curious, embrace uncertainty, and focus on learning over perfection; the skills and mindset you develop in these early days will pay off far beyond any single project.
