Service as a Software: We Sell the Work, Not the Login

I am Harshit, the founder of Mindlyft. Before this I spent six years on the customer side of software, at Adobe, New Relic and Freshworks, across more than a thousand accounts. The pattern I watched for six years was not bad tools. It was good tools with nobody to finish the work in them. Weight what follows accordingly: I sell the thing I am describing.

Every SaaS pitch I ever sat through sold the same promise in a different font: buy this and your team will do the work faster. The tool arrives. The work does not do itself. Someone still reads the transcript, opens Salesforce, updates the stage, files the Jira ticket, writes the recap, chases the renewal. The software made the work possible. It never made the work happen.

Most teams answered by adding more software. Then a person to run the software. Then an agency to run the person.

We made the wider case in Intelligence Is Cheap, Execution Is Not. This post is the practical half: what the model is, how it runs, and how to tell if it is working.

Strip the buzzword and it is one sentence: you pay for the outcome, delivered as working software inside your own stack, not for access to a tool you still have to operate.

The term is not ours. Joanne Chen and Jaya Gupta at Foundation Capital popularised service-as-software in April 2024, and Sequoia's Julien Bek put the distinction most cleanly this March: "A copilot sells the tool. An autopilot sells the work." We agree, with one amendment that matters more than the slogan. An autopilot that writes to your customer records without a human on the line is not a product. It is a liability with a nice demo. So the way we run it, every customer-facing write waits for a yes, and every action leaves a receipt you can read and undo.

Three things make it different from both SaaS and an agency:

It runs in your accounts. Your CRM, your inbox, your help desk, your sheet. Nothing is trapped in our tool, and if you leave, what we built keeps running.

It ships as software, weekly. Not a slide, not a strategy doc, a working workflow by Friday.

What we build for you becomes product. The parts that repeat across customers are promoted into ASTRA, our agentic system, which is how the cost of the second customer comes down.

A membership runs in four-week cycles. The first week is research: we map your stack, the calls where commitments get dropped, and the one workflow that would save the most hours. You leave that week with a build plan you can read in five minutes. Weeks two to four are build: one request in motion at a time, shipped weekly, iterated until it holds.

After the build, the workflow keeps running. That is the software half of the name. You can keep a membership for the next workflow, or keep what we built running on ASTRA for a flat platform fee. The price for the work is public: $5,995 per four-week cycle, and the first workflow is engineered free, before you pay anything, so you judge the work and not the pitch.

The examples in this category lean enterprise, because that is where the VC decks live. The work does not. The commitments that get dropped at a company with Salesforce, Jira and Gong get dropped exactly the same way at a ten-person company running on Google Sheets, WhatsApp and a free HubSpot.

Our first engagement with numbers is a good example of how unglamorous this is. Bijliride rents electric two-wheelers to gig workers. Their customer record lived in three places that disagreed: a set of spreadsheets, the calling platform their telecallers used, and the app's own database. We reconciled about 60,000 unique lead numbers against 138,000 registrations and found that almost half of the “leads” were already customers, including 1,518 active, paying riders who were still being cold-called. No Salesforce anywhere. That is one engagement, not a promise; your numbers depend on your stack and where you start.

The rule we work by: if your system has an API, we use it. If it has an MCP server, we use that. If it has neither, an agent can still operate the screen a person uses, under the same approval line.

Here is where this is going, and it is closer than it looks. Your SDR agent will email a prospect whose inbox agent triages it. Your support agent will negotiate a refund with a customer's purchasing agent. Agents will fill in forms, click through vendor portals and call each other's APIs, with nobody watching any single exchange.

Naval Ravikant put it in one line in September: "The future is more likely AIs fighting AIs (on behalf of humans) than AI fighting humanity." I think he is right, and the words in brackets are the part that matters for a business. On behalf of humans means somebody has to be able to say which human, and what they agreed to.

The payments world has already noticed. When Google announced its Agent Payments Protocol in September 2025, with more than sixty partners including Salesforce and ServiceNow, the core of the design was not smarter agents. It was mandates: "tamper-proof, cryptographically-signed digital contracts that serve as verifiable proof of a user's instructions." In other words, before an agent spends money, there has to be signed evidence that a person told it to.

When both sides of a conversation are machines, the scarce thing is not intelligence. It is accountability: which promises were made on your behalf, by which agent, on what evidence, and who said yes. That is the part we engineer first. The agent drafts; a person on your team approves the customer-facing write; the receipt records what changed and how to undo it. Agents can run as fast as they like on the reversible work. The commitments go through a human.

Engineering is a word people put on slides. We mean the boring parts that decide whether a rep still trusts the system in month three:

Writes are idempotent, so a retry never creates a second deal or a second ticket.

Matching is on what is actually unique, so three records for one person become one without overwriting your master data.

Every write stores what it replaced, so undo is a click, not an apology.

Permissions are scoped to the job. An agent with no delete right cannot delete, whatever the model says.

It lives where people already work: Slack, Gmail, the CRM. If a rep has to open a new dashboard to use it, it will be dead in a month.

The test for all of it is simple. Does the founder, the rep or the CSM use it on a Tuesday without thinking about it? If not, it is a demo.

The best argument against us is old and correct. Andreessen Horowitz wrote in 2020 that "you can replace the services firm, but you can't (completely) replace the services." Custom work per customer eats margin. A company that sells outcomes and does fresh custom work every time is an agency, whatever its homepage says.

There is a newer version of the same risk: compute. An agent left looping for hours can quietly cost more than the person it replaced, and founders have posted their cloud bills to prove it. Agents in our builds run on a job, with a budget, and stop.

So here is the test we hold ourselves to, and you should hold anyone in this category to it: does the second customer cost less to set up than the first? If the pieces we build never get promoted into product, the margin never moves, and we will have built a very nice agency. We would rather find that out early and say it in public than pretend.

If your team loses hours to the work between the call and the record, start with one workflow. We engineer it end to end, free, inside your stack, and you keep it either way. If you want the full menu of what that can be, from a first website to a renewal, it is in What We Engineer. If it holds, pick a Monday and we start the next one.

And if you think the whole category is wrong, tell me where. I would rather lose this argument in public than win it in a pitch deck.