We Fired Ourselves as Consultants. Here’s Why.

We Fired Ourselves as Consultants. Here’s Why.

The IT services market is worth $1.9 trillion in 2025. It’s projected to reach $4.7 trillion by 2035. Every major analyst firm agrees: IT services spending is accelerating.

So why did we fire ourselves from it?

Because the traditional IT services model — selling hours, staffing projects, building from scratch for every client, watching the code you wrote become someone else’s maintenance burden — is a race to the bottom. Margins compress. Differentiation disappears. Your best engineers spend their time rebuilding login pages instead of solving novel problems. And the client ends up with code that’s custom, fragile, and expensive to maintain.

We didn’t leave the IT services industry. We left the consulting model. What we built instead is a product engineering studio — a company that creates reusable IP and uses it to deliver client outcomes faster, cheaper, and with code that compounds in value over time.

This is the story of that transformation, the “code as asset” framework that drives it, and why we believe it’s the only model that survives the age of agentic AI.

The Moment We Knew the Consulting Model Was Broken

It was a Tuesday in 2021. We’d just shipped a Salesforce implementation for an automotive client. Six months of work. 14 engineers. The client was happy. We’d met every milestone. The project was a success by every consulting metric.

Then the client called with a “small change.” And we realized that the architecture we’d built — custom Apex classes, bespoke Lightning components, point-to-point integrations — was going to take three weeks to modify for something that should have taken three days. Because there was no reusable foundation. Every line of code was custom to that engagement. None of it could be leveraged for the next client.

The economics were stark: We’d spent six months and ~$400K in engineering time building something that had zero residual value to us. The client owned the code. We owned nothing but a case study and a depleted bench. Next quarter, we’d start from scratch again for a different client in the same industry, solving the same problems, writing the same integrations.

That’s when I wrote three words on a whiteboard that changed our company: Code is an asset.

The “Code as Asset” Framework

Most IT agencies treat code as a deliverable — something you produce for a client, hand over, and move on. It’s an expense on the P&L. It generates revenue once, through the hours billed to produce it. Then it’s gone.

A product engineering studio treats code as an asset — something that compounds in value with every engagement. Like a financial asset that appreciates, reusable code generates returns on every deployment. The economics are fundamentally different:

Dimension	Code as Expense (Consulting)	Code as Asset (Studio)
Revenue model	Bill per hour	Ship per outcome
Starting point	Blank slate every time	40–60% complete via IP
Client cost	Pays for 100% of development	Pays for 40–60% (custom portion)
Engineering value	Depleted after project ends	Compounds across engagements
Technical debt	Client’s problem	Studio’s incentive to eliminate
Margin trajectory	Compresses over time	Expands with IP portfolio
Acquisition value	Revenue multiple (2–4x)	IP + revenue multiple (5–10x+)
AI disruption risk	High (hours replaced by agents)	Low (IP feeds agents)

The compounding effect is the key insight. When we built DealerVogue’s warranty integration for our first automotive client, that code was an expense — it cost $80K in engineering time. When we deployed the same integration (with configuration) for our second client, the cost was $15K. Third client: $8K. By the fifth deployment, the warranty integration was essentially free — and it was better, because each deployment had hardened the code through production testing.

After 5 deployments: $80K initial investment had generated over $350K in revenue from an integration that now takes 2 days to configure instead of 6 weeks to build. That’s not consulting economics. That’s product economics.

What a Product Engineering Studio Actually Is

A product engineering studio is not a SaaS company. It’s not a pure consulting firm. It sits at the intersection:

We build products (IP): DealerVogue (Automotive Cloud), MobiVogue (Shopify Plus mobile), MedVogue (Health Cloud), ConnectVogue (AppExchange BYOK). These are production-grade software products with their own roadmaps, version control, and architecture standards.

We use products to deliver services: Every client engagement configures, extends, and deploys our IP products. The Vogue Protocol delivery methodology ensures consistency. CLEAN architecture ensures maintainability. TDD ensures quality. The IP is the starting point, not the deliverable.

Services improve the products: Every client deployment generates production feedback that improves the IP. DealerVogue’s warranty logic is better today than when we first built it — because five different dealer groups have stress-tested it in production. This feedback loop doesn’t exist in consulting.

The result is a flywheel: IP accelerates delivery, delivery hardens IP, hardened IP attracts more clients, more clients generate more production feedback. Traditional consulting has no flywheel. Each engagement starts from zero.

Good Karma: The Philosophy Behind the Model

We named our internal engineering culture “Good Karma.” The idea is simple: every line of code you write should create value for someone beyond the current project. If you’re writing something that only one client will ever use, question whether it should exist. If you’re solving a problem that every automotive dealer faces, build it as a reusable component.

Good Karma in practice looks like this:

Selector classes, not inline queries. A Salesforce developer writing an inline SOQL query is writing code that dies with the project. Writing it as a Selector class in the domain layer means the next project reuses it. Both take the same time. One creates an asset. The other creates a liability.

Domain services, not Trigger handlers. Business logic in a Trigger handler is locked to one object. Business logic in a Service class is reusable across Flows, Apex, APIs, and Agentforce agent Actions. Same logic, different architecture — vastly different residual value.

Vogue Accelerators, not project templates. A project template is a starting checklist. A Vogue Accelerator is a managed package with its own test suite, version history, and deployment pipeline. One is a document. The other is an asset on the balance sheet.

Open-source contributions, not locked IP. Good Karma extends beyond Xillentech. We contribute to the Salesforce developer ecosystem because a healthier ecosystem means better tools, better talent, and better outcomes for every engagement. Karma compounds.

Why This Model Survives the Age of Agentic AI

Here’s the uncomfortable truth that every IT consulting firm should be reckoning with: agentic AI is coming for billable hours.

When an Agentforce agent can write Apex code, configure Flows, and set up standard Salesforce deployments, the value of a consultant who does those things manually drops. MIT found that purchasing AI from specialized vendors succeeds 67% of the time versus 33% for internal builds. The consultants who survive are the ones with domain expertise the AI doesn’t have.

What AI can replace: Writing standard Apex classes, configuring basic Flows, setting up permission sets, building standard reports, creating custom objects. These are the “hours” that traditional consulting sells. They represent 40–60% of a typical Salesforce implementation.

What AI cannot replace: Domain-specific architecture decisions (should warranty logic live in a Platform Event or a scheduled batch?), integration design with OEM systems that have undocumented APIs, bounded autonomy configuration that requires understanding regulatory risk, and the accumulated judgment from deploying the same solution across multiple clients in the same industry.

The studio model is AI-proof because: Our value isn’t in writing code — it’s in owning IP that encodes domain expertise AI doesn’t have. DealerVogue’s warranty integration works not because the code is clever, but because it encodes decisions about how automotive warranties actually work in production — decisions that came from five real deployments, not from a training dataset. When AI can write the basic Apex, our accelerators become even more valuable: they’re the domain knowledge layer that sits on top of AI-generated code.

The Numbers: Consulting Economics vs. Studio Economics

Traditional consulting: Average billable rate $150–$250/hour for Salesforce consultants. 60–70% utilization target. Revenue scales linearly with headcount. Margins: 15–30% after bench costs, sales, and admin. Hiring one more engineer generates one more engineer’s worth of revenue.

Product engineering studio: IP products deployed on outcome-based pricing. Utilization is less relevant because IP does the heavy lifting. Revenue per engineer increases with each deployment because the IP handles the base workload. Margins: 35–50% on IP-leveraged engagements. Hiring one more engineer improves the IP for every future client, not just the current one.

The acquisition math: A consulting firm sells for 1–3x revenue because the revenue walks out the door when consultants leave. A product company with growing IP sells for 5–10x+ revenue because the IP is a durable asset. A product engineering studio with both IP products AND consulting revenue occupies the space between — significantly more valuable than pure consulting, with the optionality to scale the product side independently.

What We’d Tell Other IT Agencies Considering This Shift

1. Start with one industry vertical, not a horizontal platform. We started with automotive because we had deep domain expertise. DealerVogue was built from real client problems, not a whiteboard exercise. Pick the industry where you’ve done the most implementations and build IP from the patterns you already know.

2. Extract IP from existing projects — don’t build in isolation. DealerVogue’s warranty module started as custom code in a client project. We recognized the pattern, abstracted it, and turned it into a reusable component. Every consulting firm has IP hiding in their project archives. The question is whether you’re intentionally extracting it or letting it die with the engagement.

3. CLEAN architecture is non-negotiable. Reusable code requires reusable architecture. If your developers write business logic in Trigger handlers and inline SOQL, the code is single-use by design. The CLEAN architecture investment (Controllers → Services → Domains → Selectors) pays for itself by the second deployment.

4. Budget 20% of every engagement for IP extraction. This is the hardest discipline. When a client engagement produces a reusable pattern, allocate 20% of the engineering budget to abstracting, testing, packaging, and documenting it as reusable IP. This is an investment, not an expense — but it feels like an expense in the quarter you make it.

5. Hire builders, not staffers. The mindset shift is the hardest part. Consultants think in projects. Product engineers think in versions. You need people who see beyond the current engagement to the IP that will serve the next ten. This is a hiring filter, not a training program.

Where Xillentech Is Today

60+ engineers across four practices: Agentic AI & Automation, Salesforce Architecture, Unified Commerce (Shopify Plus), and Product Engineering.

4 IP products: DealerVogue (Automotive Cloud), MobiVogue (Shopify Plus mobile), MedVogue (Health Cloud), ConnectVogue (AppExchange BYOK). DealerVogue is in AppExchange Security Review.

Salesforce ISV + Consulting Partner: We build AND implement. This dual model is rare — most firms do one or the other. The combination is what makes the flywheel work.

Shopify Plus Partner: MobiVogue extends the product-led model into commerce.

8+ Agentforce certifications: Not just Salesforce certified. Certified on the agentic AI platform that’s redefining every Cloud.

Global delivery: Headquartered in Ahmedabad, India with offices in the US, UK, Canada, and UAE. The IP travels; the engineering team doesn’t need to.

We didn’t fire ourselves as consultants because consulting is bad. We did it because consulting alone isn’t enough. The agencies that thrive in 2026 and beyond will be the ones that own something — IP, methodology, reusable architecture — that compounds in value with every engagement. The ones that sell hours alone will compete on rate and headcount until AI makes both irrelevant.

Code is an asset. Every engagement should make it more valuable. That’s the whole philosophy.