I Didn't Want to Build a Company That Just Delivers Projects
A project ends at handover. I wanted Incrix to build things that last, learn and get better. This is the conviction behind that choice, and what it costs.
A project ends with a handover. I wanted to build a company that didn't have to start from zero every time one ended.
That's the simplest way I can explain one of the most important choices behind Incrix. It's not that I dislike client work; we do a lot of it, and we're good at it. It's that I didn't want client work to be the only thing we did. The question of product vs service company isn't an abstract strategy debate for me. It's about what kind of company I want to spend my life building.
I'm Avinash, and I lead Incrix. We started in 2019 in Kovilpatti, became an LLP in 2021, and today build software, hardware and products across five streams. This is the conviction behind the products, and what it costs.
TL;DR
- Projects reset; products compound. I wanted some of our work to accumulate.
- Services aren't the enemy. They keep us honest and close to real problems.
- Ownership changes people. Teams that live with their decisions make better ones.
- Classory and our boards are the conviction made real.
- It's slower and riskier. I think it's worth it anyway.
What a project-only company feels like from the inside
I'll describe this as a pattern rather than a story, because it's a pattern most people in services will recognise.
In a company that only delivers projects, value tends to reset. You win the work, build it well, hand it over and move on. The knowledge you gained lives in a handover document and in the heads of whoever worked on it. The next engagement starts close to the beginning again.
Your pricing is tied to time. Your growth is tied to headcount. And your reputation is only as strong as your most recent delivery. None of that is wrong. But it puts a ceiling on what a company can become, and I didn't want Incrix to have that ceiling built in.
I didn't want our best work to belong to whoever signed the last invoice. I wanted some of it to belong to us, and to get better every year.
Product vs service company: what the difference really is
People often frame this as "services make money now, products make money later". I think the real difference is deeper than timing.
| Service company | Product company | |
|---|---|---|
| What you sell | Your team's time and skill | Something that works without you in the room |
| What compounds | Reputation | Reputation, and the product itself |
| Who owns the decisions | The client, usually | You, and you live with them |
| How you're measured | Delivered to scope | Still being used, and improved |
| Where the risk sits | Mostly with the client | Mostly with you |
The last row is the one that matters most. A product company takes on risk that a service company can pass on. That's exactly why it's harder, and exactly why it's worth doing. Risk you carry yourself is risk you learn from.
I'm not against services
I want to be clear about this, because the conviction is easy to misread.
Incrix does a lot of service work. Our branding stream has delivered 1000+ projects. Our studio makes brand films and ad films. Our software team builds applications for clients, and our hardware team has done NDA work, such as a Wi-Fi control board retrofit for legacy weighing scales and a point-of-care Wi-Fi height-measurement device.
Services keep us honest. They put us in front of problems we'd never have invented, in conditions we can't fake. What I didn't want was a company where services were the ceiling. I wanted them to sit alongside products, so the lessons from one could feed the other.
Ownership changes people
What I've learned is that ownership doesn't just change the product. It changes the people building it.
When a team knows it will maintain what it ships, it thinks differently. It asks about year three. It questions features that sound good but will be painful to support. It cares about architecture, because architecture is what it'll be living inside. Our software approach, understanding the problem and designing on "cost-effective, maintenance-friendly serverless architecture", comes straight from that mindset.
I think a product mindset is one of the most valuable things a young team can develop, and it's hard to develop if you never own anything. Product School is a good place to start if you want to learn how product teams think about this.
Classory: the conviction made concrete
Classory is our own SaaS product, an AI LMS that lets academies, institutions and educators run their own white-label learning platforms. For me, it's the clearest expression of why we build products.
Two decisions in Classory say more about our values than any mission statement.
It's white-label. Academies run Classory under their own brand. We chose to make their identity the one learners see, not ours. That's a product decision that only makes sense if you believe your job is to make other people successful.
It's 0% commission with your own gateway. Educators who connect their own payment gateway don't pay Classory a commission on their sales. Our values say "equity in mind, dignity in action", and I wanted our pricing model to reflect that, not just our About page.
You can't make choices like these in a project. There's no long-term relationship to design for. Only a product lets you encode what you believe into how something works. The company perspective on this is in Why We Build Products, Not Just Projects.
Hardware: owning the stack
The same conviction runs through Incrix Automation. We could have stayed a hardware design service, building boards to other people's specifications and handing them over. We do that work, and we value it. But we also build our own boards: Horizon Gen 1, Twinedge Dev V2, Horizon Dev-2 C6 and Hexon Atom C6, along with education kits.
And the long-term vision is a product roadmap: from microcontroller boards, to our own MPU boards, to our own SoC. That's not the ambition of a company that only delivers projects. It's the ambition of a company that wants to own what it builds, from silicon to cloud, engineered in India. You can see the current lineup on our hardware products page.
The honest trade-offs
I don't want to pretend this choice is free.
Products are slower. They need investment long before they return anything. They demand support, maintenance and patience after the excitement of launch has faded. They force you to sell something that doesn't exist in its final form yet. And when a product decision is wrong, there's no client to share the consequences with.
I believe it's worth it anyway. For me, the product vs service company question was never about which model is easier. The alternative is a company that works very hard and never quite accumulates anything of its own.
The principles I hold
- Build some things you keepClient work is valuable. But a company should own at least some of what it creates, and keep improving it.
- Let services feed productsReal problems from real clients are the best raw material a product team can have.
- Put your values in the productPricing, defaults and design choices say more about what you believe than any mission statement.
- Carry the risk you want to learn fromThe discomfort of owning outcomes is where a team actually grows.
- Think in versions, not deliveriesVersion one is the beginning of the work, not the end of it.
Where this leaves us
I didn't want to build a company that just delivers projects. I wanted to build one that delivers projects well, and builds products that get better every year. Classory and our boards are where that conviction became real. There's more to build.
If you want to know where this thinking started, read What Building a Company at 22 Taught Me. For the full picture of what Incrix is building today, start with What Are We Actually Building at Incrix?, and for the bigger vision behind it, Building From India, For the Real World.