Service as a Software
How Fractional CTOs, freelancers and employees can turn repeated work into AI-powered systems
I’m Sergio Pereira, and this is my newsletter 👋
Over the last few weeks I’ve been writing a lot about the changing economics of building software. And last week I explained how non-technical Founders can build tech startups in 2026:
AI made code cheaper. Spec-driven development makes AI-assisted delivery more deterministic. Smaller teams can now ship more than much larger teams did just a few years ago. And this changes how Founders buy technical work, how Engineers create value, and how Fractional CTOs like me structure engagements.
Today I want to zoom into one specific idea that I think will matter a lot over the next few years: Service as a Software.
Not Software as a Service, the long established business model. It’s actually Service as a Software. Kind of the opposite.
The idea is simple: Instead of building software and selling it on a subscription based, as if it was a service (thats the traditional flavour of SaaS, Software as a Service). In Service as a Software you sell a service, you position and price it as a service towards clients, but under the wood it’s a product, meaning it’s all automated.
YCombinator, the famous startup accelerator, has been pushing this as the new business model for the age of AI, where you put people in the client-touching parts of the business (especially sales and onboarding), and then automate everything else with AI agents and pre-defined workflows.
While it’s a new opportunity for everyone building new companies, especially because historically companies invest much more in services than they do in software products. Today I’ll approach this opportunity from an individual point of view. How can I, and each of you readers, apply this Service as a Software principal in our daily work, either as a Fractional CTO, a freelancer, or even a full time employee.
Take the parts of your work that repeat often, those things you do again and again for clients, colleagues, stakeholders, or your own team, and turn them into software-like workflows powered by AI. Not necessarily as a SaaS product that you sell externally, as a public tool. Often just as your own internal operating system.
I’ll make this concrete.
If you’re a Fractional CTO, a freelancer, an agency owner, a consultant, a Product Engineer, or even a full-time employee, there are probably parts of your job that repeat constantly.
For example:
turning meeting transcripts into product requirements
turning product requirements into Jira tickets
turning client feedback into updated mockups
reviewing a cloud bill and identifying obvious waste
performing a scalability assessment from infra diagrams
reviewing a codebase and summarizing technical debt
converting sales calls into product roadmap insights
turning user interviews into feature priorities
creating onboarding checklists for new clients
reviewing privacy and security risks before a launch
transforming messy Slack threads into decisions and next steps
summarizing bug reports into reproducible engineering tasks
converting a founder’s brain dump into a clean product spec
checking server logs and correlating with customer support tickets
None of this is glamorous. But this is where a lot of time disappears. And this is exactly the type of work AI is great at, if you give it the right context and the right process.
That last part matters. This is not about randomly prompting ChatGPT and hoping for magic. That’s the same mistake people make when they vibe code software products. The trick is to productize the process.
Take something you already know how to do well, write down the way you think about it, define the inputs, define the output format, encode your standards, and reuse that workflow every time the task appears again.
In other words, apply spec-driven development to your own work. Not necessarily to write code, but just to reduce the time sink around all the other work.
Let’s say you frequently turn meeting transcripts into Jira tickets.
A weak version of this is: “Here’s a transcript. Create tickets.”
A better version is: “Here’s how I think about product scope. Here’s how I separate user stories from technical tasks. Here’s how I define acceptance criteria. Here’s what I consider an edge case. Here’s how I tag priorities. Here’s the output format I want.”
Then every new meeting transcript becomes just new domain data being passed through a process you already defined. That is Service as Software applied to your own work.
The same applies to client feedback. Instead of manually reading a long email thread, messy Slack message threads, and several comments on a mockup, you can have a workflow that extracts:
what the client is actually asking for
what changed since the previous version
what is a real requirement vs a preference
what needs founder approval
what should become a product decision
what should become design work
what should become engineering work
Again, the value is not “AI summarizes text”. That’s just the basic part. The value is that the AI follows your way of thinking, your standards, your workflow, your judgment.
That’s where so many technical people overcomplicate this. They spin up an agent framework. They build a local OpenClaw setup. They spend three days wiring tools together. Then the thing needs maintenance, breaks, and creates yet another system to babysit.
Most of the time, the useful version is much simpler. You need just two things really:
New domain context
Your predefined process
The domain context might be:
a meeting transcript
a client email
a Slack thread
a PDF report
a design mockup
a code repository
an AWS bill
an infra diagram
a bug report
The process is your reusable prompt, Claude Skill, internal agent, or small tool trained on your knowledge and preferences.
It can be very simple. A well-written prompt saved in ChatGPT. Or a Claude Skill. Or a lightweight internal tool. And a custom workflow that wraps all of the above.
The point is not to build the fanciest system. The point is to make it convenient enough that you actually use it every day.
I’ve been increasingly doing this in my own Fractional CTO work. Some parts of the job are still deeply human, obviously. I’m the one talking with Founders, understanding business context, making decisions and assessing tradeoffs, and ultimately building trust.
However, many of my workflows under that can be productized into easy modules that I apply as needed. Like crunching a meeting transcript into product descriptions or a lovable mockup, or updating the spec in the repo after relevant messages on slack.
The busy work alleviates a lot the effort required, and once that happens the business model changes. There are two ways to benefit from this:
I can take outcome-driven engagemetns. This is the model I’ve been encreasingly leaning into more with early-stage startups, instead of selling hours, I sell outcomes, and since I productised the whole engagement, every client goes through a repetitive set of phases where I commit to the same rough set of deliverables. Because my process is more crystallized now, and because AI gives me much more leverage, I can deliver those outcomes with a fraction of the effort it would have taken a few years ago. That creates a better deal for everyone, he Founder gets clarity, speed, and accountability, and I get to do higher-leverage work.
The second model is still time-based work. Retainers, hourly consulting, or even full-time employment. That does not go away. But even there, Service as Software can be applied to become more effective, to deliver faster, to reduce latency and busy work. If you’re on retainer or working as a full time employee, you create more value in the same time. That’s a win-win for you and the company, especially if your job includes repetitive knowledge work, as most jobs do.
This is why I think freelancers, fractional workers, agencies, and employees should all pay attention to this shift. You don’t need to turn everything into a startup product. But you can turn your own knowledge into a reusable AI workflow that makes you much more efficient and productive at what you already do.
I wrote about spec-driven development in more detail in a previous edition of this newsletter:
And this is the exact process I’ll be teaching in a few weeks with my friends at GenAI Works. The course is called Ship Reliable Software Faster with AI, and I’ll break down the full process step by step, from idea to production, and how to use AI without creating chaos.
Finally, I’m also building teams to do this kind of work with early-stage startups. If you’re a Product Engineer, AI Engineer, or CTO who likes outcome-driven work, spec-driven development, and building with AI in a disciplined way, reach out to me at sp@sergiopereira.io. I’m happy to connect.
See you next Friday,
Sergio Pereira