I’m Sergio Pereira, and this is my newsletter 👋

Over the last few weeks I’ve been writing about the changing economics of building software, the rise of outcome-based engagements, and why AI-assisted development only works reliably when paired with a proper spec-driven process.

Today I want to make this more practical, especially for non-technical founders. Because if you’re starting a tech startup in 2026, the first steps look very different from what they looked like just a few years ago. And honestly, this is one of the most exciting changes I’ve seen in my career.

A few years ago, if you were a non-technical founder with a software idea, the path was painful. You probably needed to:

• raise money before building anything

• find a technical co-founder

• hire an agency

• or convince engineers to join before there was much to show

That was hard. Not because founders lacked ideas, but because software was expensive to build. Turning an idea into something visual, clickable, and testable required designers, product managers, engineers, and weeks or months of work.

Today, that changed.

A non-technical founder can now do a huge amount of the zero-to-one work alone, or with very light help. You can use ChatGPT or Claude to explore the market, define personas, and map workflows. You can create mockups in Lovable, and put something clickable in front of potential clients. And you can do all of that with under $100 per month in subscriptions.

That is not a small change. It is groundbreaking. It means that founders no longer need to raise money just to find out whether anyone cares.

They can build a first version of the idea, show it to people, get reactions, iterate, and sometimes even get letters of interest or early commercial commitments before writing a single line of production code.

This is exactly the kind of work I’m doing with early-stage founders right now. And interestingly, a lot of it is not something only I can do. Founders can do a lot of this themselves. In fact, I think they should.

If you’re a founder, you should absolutely use AI tools to clarify your thinking before spending real money on development. Do not wait for permission. Do not wait for funding. Do not wait until everything is perfectly defined. Get something in front of people.

That is the opportunity. But there is also a limit. And this is where I want to be very clear. A Lovable prototype is not a real product, a clickable demo is not production-ready software.

A mockup that helps you validate interest is not the same thing as software that clients can rely on. This distinction matters.

I’m not saying this to dunk on non-technical founders using AI. Quite the opposite. I love that founders can now take initiative and move faster. But someone needs to be the grown-up engineering person in the room and say: “This is great for zero-to-one. It is not enough to build the business on top of.”

Because once real clients start using your product, the game changes. Now you need to think about security, data privacy, reliability, scalability, integrations, edge cases, permissions, audit trails, backups, observability, etc. None of this matters much when you’re showing a prototype to five friendly people. All of it matters when a paying client depends on your product.

If you’re building in healthcare or fintech, one careless data leak can kill the company. If you’re building B2B software, one messy onboarding with your first big client can destroy trust. If you’re building a consumer app and your launch works too well, your backend collapsing on day one can waste months of momentum.

This is the gap founders need to understand. AI tools made prototyping dramatically easier, but they did not remove the need for real engineering. They simply changed when and how you need it.

The old path was: Raise money first. Hire a team. Build product. Then validate.

The new path is: Explore the market. Prototype cheaply. Validate with real conversations. Get early signal. Then bring in technical depth to turn the prototype into a product.

That is a much better path. It is cheaper, faster and much lower risk. And it puts founders much closer to customers from day one.

But when things start to get serious, and you need to make the transition from prototype to product. That is where I typically help.

I work with non-technical founders as their technical right hand. Sometimes they come with an idea, or a Lovable prototype, or an MVP that kind of works, some actually have early clients and a product that is already starting to crack.

My job is to help turn that into a reliable and scalable product that fuels the business goals.

The process starts with clarity. Before building, we define:

• what the product needs to do

• who it serves

• what workflows matter

• what should happen in each scenario

• what can go wrong

• what should not be built yet

Then we turn that into a proper spec, and that spec becomes the source of truth for the product. Only then do we use AI-assisted development tools to build the product.

This is the spec-driven development process I’ve been writing about, like in this article:

The key rationale of SDD, and AI-assisted Software Development more broadly, is that a Founder, a strong Product Engineer, and a Fractional CTO can now do work that would have required a much larger team a few years ago.

It does not mean software is easy, but it means that the leverage changed. The Founder can do more before hiring. The Engineer can deliver more with the right process. And the CTO can focus less on managing a large team and more on making the right product and architecture decisions, and (mind you) even coding himself.

This is why I think 2026 is an amazing time to start a software company. And if you’re a Software Engineer, it’s actually a great time to work with startups, and build software leveraging cutting edge tools and processes.

This is exactly the process I’ll be teaching in June, at the course called Ship Reliable Software Faster with AI, where I’ll break down the full Spec-Driven Development process step by step, from idea to production, and how to use AI without creating chaos.

In the meantime, I’m building a team for a Canadian Healthcare Startup to do exactly this kind of work. This type of opportunity comes up every now and then. So, if you’re a Product Engineer, AI Engineer, or CTO who likes working with founders, building products from zero-to-one, and using AI tools in a disciplined way, reach out to me at sp@sergiopereira.io.

See you next Friday,

Sergio Pereira

Last week I wrote about what 15 years of hiring Software Engineers taught me, and how the market moved through very different phases.

From local hiring and university credentials, to hypergrowth hiring, remote teams, and now AI-first engineering teams operating with spec-driven development processes.

Writing that got me thinking that the most recent changes in my hiring processes happened as a result of fundamental changes in my own work as a Fractional CTO, and in the broader market segment of tech startups.

Today I’m writing about the shift towards outcome-based engagements with early stage startups.

And this is a personal one, because I was a Startup Founder twice. I know that startups are hard, and I love working with entrepreneurs who know their industry well, who have spotted a promising market opportunity, and who have tremendous energy to pursue that vision.

What they lack is understanding technology, and the ability to define and build a product that their clients will pay for. That’s where I step in.

Very often these entrepreneurs have limited budget, incomplete information, perhaps some vibe coded product that is not quite there yet, clients requesting different features, investors asking difficult questions, and a million priorities competing for their attention.

That environment is chaotic, stressful, and absolutely not for everyone. I learned over the years that most Engineers dislike that lack of structure. But personally, I love it.

The early stage startup phase is where I can create the most value. That intersection of being a thought partner, a product manager, a system’s architect, and then quickly becoming a builder and assembling a team around me. At this point it comes quite natural, and I think that having the optionality, I should steer towards the type of work that I like the most.

Over the last 12 years, I worked as a Startup CTO in different contexts, I built regulated Fintech products from the ground up and scaled them to processing tens of millions of $$ every year. And over the last four years, as a Fractional CTO, I’ve worked with around 20 startups in different industries, stages and team setups.

And after seeing this pattern again and again, I’ve tested different engagement types and work dynamics with Founders over the years. I’ve never loved the “buy my time”, or “pay me every month and we’ll see what happens” type of engagements, even though I’ve done hourly and retainer engagements dozens of times each.

The part I like the least about such open ended engagements is that is leaves a lot of room for ambiguity, and a constant feeling of seeking scope and proving delivery, just to continue the engagement.

I learned that there’s a better way. And as I niche down to non-technical Founders in the early days of launching their tech startup, the goals tend to be around the same. They need to define the product, build it, get clients, some need to raise some funding in the process, and ultimately find product market fit and scale from there.

So I started structuring my engagements exactly around that. There are clear phases, and for each phase there’s a clear set of deliverables and goals to achieve. I’m a very goal oriented person, so this alignment of incentives comes quite natural to me.

And above all, I make it outcome oriented, meaning that my payments are tied to those deliverables. And this is the important part. I’m de-risking it for clients who already have plenty of risk and uncertainty to handle. They know that from the tech side of the house they can trust me to shape the product, ship it and build a team along the way to scale it once the time is right.

I got this idea from some Fractional CMOs whom I’ve worked with at clients over the years. In Marketing it’s quite common to pay for results, and that’s super attractive for clients. So I figured that I should try the same in tech, and it works equally well, as least for me.

And take a look at the Founder’s perspective:

• You’re a non-technical founder

• Hiring Software Engineers is scary

• You often don’t even know exactly what you’re buying

• You don’t know if a 3-month estimate is reasonable

• You’ve hired dev agencies in the past and got screwed

So outcome-based work feels safer, you know what you’re paying for, everyone knows what success looks like, and success can be evaluates based on the delivery.

From my side, it forces accountability, which is something I’ve always been very comfortable with, even in the chaotic context of early stage startups. There’s much less counting hours, meetings, documents or “technical complexity”, which makes the engagements sharper around the goals. I either deliver the outcome, or I don’t.

Of course, this only works if I know what I’m doing, and I personally like it more this way. I’ve done it enough times so that when a founder comes to me, I usually know what they actually need, how to stress test their assumptions, highlight the constraints, and get the work done.

With AI-assisted development and a spec-driven development process, I can take a much more deterministic approach. I spend time upfront understanding the business problem. I talk with the founder, look at the current product if it exists, review client needs, check theirs constraints, and clarify what outcome actually matters. Then I define the product scope, and work with the Founder on what’s a realistic MVP for their go-to-market. After that it tends to be more traditional work of assembling a team and scaling a product. But in the early days, I love being this technical right-hand person of non-technical Founders, and fixed scope engagements have proved to be the best arrangement for that.

And for most early-stage Founders, the first engagement is not really about the first deliverable. It’s about trust. If I help a Founder take an idea to an MVP, or fix a broken product, or ship a critical feature, the next conversation often becomes much more strategic:

• Can you help me scale this?

• Can you help me hire the team?

• Can you stay involved as our Fractional CTO?

• Can you help us make the technical roadmap for investors?

Not as a vendor selling hours. But as the technical right hand of a Founder who is building a real business. And I think this is the direction the market is moving.

Founders want less ambiguity. Engineers want more meaningful work. AI made implementation faster. Smaller teams made ownership more important. And outcome-based engagements fit that world much better than the traditional “sell my time” model.

This also explains why demand has been growing for me recently, and more importantly, why that demand is becoming more structured. That consistency makes it easier to define the work, price it, delegate parts of it, and bring other strong people into the delivery.

Which brings me to something important. I’m hiring and partnering with Product Engineers and AI Engineers to work with me on these engagements with early-stage startups. If that sounds like you, reach out to me at sp@sergiopereira.io and let’s talk.

This is also exactly why I keep talking about spec-driven development, as the process that makes this kind of work possible for me in a predictable way. Without such determinism, outcome-based engagements are dangerous. With it, they become much more manageable.

I wrote about this process in a previous edition of the newsletter:

And this is also what I’ll be teaching with my friends at GenAI Works, in my cohort-based course Ship Reliable Software Faster with AI. I’ll break down the full Spec-Driven Development process step by step, from idea to production, and how to use AI without creating chaos. It has been moved to June, and I look forward to meeting many of you then.

See you next Friday,

Sergio Pereira

Last week I wrote about why remote teams are set to win in the AI era, and how smaller, outcome-oriented teams are changing the way we build software.

Writing that has got me thinking about another topic I’ve experienced very closely over the last 15 years: Hiring Software Engineers. And, as a CTO, how I’ve changed my hiring process again and again over the years.

I hired my first Software Engineer in 2011. And honestly, the way companies hire Engineers today barely resembles what it looked like back then.

I’ve now hired across:

• consulting companies

• my own startups

• hypergrowth VC-backed startups

• fully remote global teams

• and more recently, AI-first engineering teams operating with spec-driven development processes

The market changed dramatically in each phase. But interestingly, some of the strongest signals stayed surprisingly consistent.

Let me break it by phases, and tell you how the process has changed, from my perspective as a hiring CTO:

2011: degrees, local markets, and probation periods

My first hiring experience was at Accenture, where I started my career. Back then, the process was extremely simple. We mostly hired freshers, and the main filtering mechanism was academic background. The process was entirely local:

• local universities

• local candidates

• local office

Everyone knew which Computer Science courses had the strongest reputation, and that heavily influenced hiring decisions. There were no deep technical rounds. No take-home projects. No live coding. Even salaries were equal for everyone joining at that level, no negotiations at all. People would often start working almost immediately, and there was usually a probation period where performance issues were handled very quickly.

You might say it wasn’t a very good process, and I’d absolutely agree with that. But frankly, I didn’t know better, and even if I did I was operating inside an org that didn’t leave me much room to improve it.

Looking back, that hiring process was mostly about reducing risk. And honestly, Software Engineering felt relatively “elite” back then, even though we were in a small country going through a huge financial crisis with very low salaries (I only know that now, in hindsight. I don’t miss those times at all.

2014: my first startup changed everything

In 2014 I founded my first startup, Clickly. For the first time, I had full ownership over the hiring process, and full accountability if it went wrong. The problem was that I had almost no budget, so I had to get creative. I started looking for people very differently.

Instead of optimizing for university prestige, perfect CVs or polished interview performance. I started looking for side projects, startup ambition, curiosity, critical thinking. Ultimately, for people comfortable operating under uncertainty. And this was one of the biggest lessons of my career.

University work optimizes people for clear requirements, well-defined problems, predictable environments. But startups are the exact opposite. You rarely know exactly what should be built. Requirements change constantly. Half the job is figuring things out as you go.

So, during the interviews during that period, I learned to paid a lot of attention to motivation, appetite for ownership and ability to think independently. And honestly, I’m very proud of where that team ended up.

That startup collapsed three years later, which is part of the game. But most Engineers from that team have had pretty great careers in the following years. It’s very rewarding to look back at that phase.

2016–2022: the hypergrowth years

Then came the hypergrowth phase. This was a completely different market. In all companies I worked for during those years, hiring became one of my main KPIs as the CTO. At some points I was hiring more than 10 Engineers per quarter.

It was a different market from today’s. Demand massively exceeded supply, it was probably the best period in history to be a Software Engineer. Everyone was employed, and still had a bunch of recruiters in their DMs with new job opportunities.

Companies were competing aggressively for talent, compensation exploded, and everyone was trying to scale engineering teams as fast as possible. From a CTO perspective, let me tell you, it sucked. I’ve always enjoyed more building than managing, and during that phase I was several times put under pressure for hiring beyond a certain headcount. It was a period where headcount equalled growth, at the eyes of many VCs and industry players. Crazy stuff, now that we look back, a startup would raise many millions and a big chunk of that would be deployed in hiring Engineers to build a product, in many cases even before any traction.

As a player in that game, I was hiring non-stop. And this was the exact time when remote work changed my trajectory. Honestly, it was one of the biggest breakthroughs of my professional life. I didn’t live in a major US tech hub myself, yet suddenly I was working with US startups remotely. The same thing happened to many engineers I met along the way, people from India, Brazil, Poland, and even less talked about places like Uganda, the Caribbean, Armenia, etc etc. Suddenly we were working inside international startups competing globally.

It was a huge unlock for me, for all the people who tapped into such international remote careers, and I think it was a huge unlock for our industry. Think again, why would you compete for Engineers in the Bay Area who are already earning $300k/y, when you can hire someone elsewhere who’ll work remotely for you for a third of that, and still be among the highest earning percentile in their city.

Remote work flipped the challenge for me. I no longer had challenges attracting Engineers, even in a heated market. However, I had the big challenge of filtering, interviewing and onboarding, which was quite a lot of work.

During those years I experimented with every hiring process imaginable:

• live coding

• take-home assignments

• paid trials

• pair programming

• “system design” sessions

And I learned something very counterintuitive, but quite obvious in hindsight: Many great Software Engineers are terrible interviewees.

Some of the best hires I ever made performed poorly in technical rounds, as many people get nervous and struggle under artificial interview pressure. I made the call to hire some of those people, despite terrible interview scores, and turns out several of those became extremely impactful Engineers once inside the team.

That experience made me much more skeptical of over-engineered interview processes. Similar concerns around stress-heavy hiring pipelines have also been raised in more recent research on tech hiring practices, which again seem obvious in hindsight, but counter intuitive to everyone involved in recruitment.

At some point in my trajectory as a CTO I realized that interviewing and engineering are different skills. There is overlap, of course, but much less than many companies assume.

2023–2026: the noisy market

The last few years brought another huge shift. The market cooled down, layoffs happened, supply increased dramatically. And, on top of that, AI entered the picture.

Now we live in a market where:

• remote roles instantly receive hundreds of applicants

• candidates use AI to optimize CVs and applications

• companies struggle to distill signal from noise

From a CTO’s perspective, this created a completely different challenge. It’s no longer hard to get candidates, it’s harder than ever to identify great ones.

Especially because many companies are now operating with smaller teams, higher expectations per individual, more AI leverage This shift is visible across the industry, with many companies explicitly restructuring around smaller, AI-assisted engineering teams. And while the strongest engineers have adapted quickly, many people are lagging behind. It’s especially challenging for those people working in companies with legacy processes, under “AI-skeptical” leadership, those people will become handicapped for the next years of their career, unless they proactively build side projects and uplevel themselves outside their job, which in fact many of us are doing anyway.

What I optimize for today

Today, I care much less about academic prestige, perfect interview performance, memorized algorithms. And much more about ownership, product thinking, communication, ability to operate independently, engineering judgment. What many people now call the Product Engineer. People who understand the business, can work across the stack, think in systems, and own outcomes instead of just tickets.

Another important shift is that all my teams now operate with a spec-driven development process, which means I actively look for people who are aligned with that way of working.

Not the pure “vibe coding” engineer who prompts randomly until something works. And also not the engineer who rejects AI completely and insists on writing everything manually as a matter of pride.

Like many things in life, the best trade-off is somewhere in the middle. The strongest engineers I work with today are:

• senior enough to recognize good software architecture

• experienced with code reviews and production systems

• disciplined about managing tech debt early

• But also fully onboard with using AI tools aggressively to speed up execution.

Fortunately, there’s a growing number of engineers operating this way. And honestly, I learn a lot from the people I hire into my teams these days.

One unexpected side effect of this newsletter is that it became one of my best recruiting channels. As a Fractional CTO, my hiring needs change constantly:

• different tech stacks

• different industries

• different seniority levels

• different geographical constraints

• different salary budgets

And many of the strongest engineers I’ve met in recent years came through this audience.

In recent months, I’ve been having more demand than I can personally supply, and I’ve either offloaded clients or hired people to work in my teams. If you’re a Product Engineer, AI Engineer, or CTO working in this space, and you’re interested in opportunities to work with me or with fellow CTOs in my network, reach out to me at sp@sergiopereira.io. I’m always happy to connect with great people.

More broadly speaking, if you’re an engineer reading this, my advice is simple, don’t obsess over Leetcode, perfect interview performance, memorizing frameworks, and all those legacy interview practises.

Focus on becoming someone who:

• builds things

• owns outcomes

• communicates clearly

• understands products and business constraints

• and can operate independently

The tools changed. The market changed. The type of opportunities changed. But after 15 years of hiring engineers, the strongest signal is still ownership. Engineers who can pick a problem, find a solution and ship it to production. Believe it or not, that has always been quite a rare finding throughout every phase I described here.

This is also exactly the process I’ll be teaching in a few weeks with my friends at GenAI Works. I’ll run a cohort-based course where I break down my Spec-Driven Development process step by step, from idea to production, and how to use AI without creating chaos. It’s called Ship Reliable Software Faster with AI.

See you next Friday,
Sergio Pereira

Last week I explained how the playbook is changing to build software product, and especially why Startup Founders are allocating their budgets in different ways than they did for most of the last decade.

Today I’m changing gears to a very familiar topic for most readers. If you’ve been following me for a few years, you know that I used to write a lot about remote work Then I mostly stopped.

Not because I changed my mind, I’ve worked remote for over a decade and I love it. However the whole Remote Work topic became a bit exhausting online. It has turned into a very loaded debate in recent years:

• Big companies pushing return-to-office narratives

• Others defending remote work at all costs

• Endless hot takes on both sides

I didn’t really enjoy feeling like I was in a trench, while simply writing about my work. And to be fair, some of the criticism of Remote Work does have grounding. There were cases of people abusing remote work:

• faking identities in interviews

• juggling multiple jobs and under-delivering

• breaking contractual expectations

Those things gave fuel to the anti-remote narrative. It’s one of those cases where bad behaviour from a small number of remote workers affects negatively the perception about the millions of remote workers around the world.

Over the last decade, I’ve worked with hundreds of remote professionals. Different countries, different roles, different levels of seniority. And the overwhelming majority were high performers.

People who knew their craft, delivered good work, communicated well and took accountability for their work

On top of that, they had more enjoyable lives:

• no daily commute

• more control over their time

• the ability to live where they want

For me personally, remote work meant being able to live in a small Portuguese village while working with companies in the US, building products for global markets, and earning far beyond what the local economy would allow. I’m very grateful for that. And if you’ve been following me for a while, you already know this.

So why am I writing about remote work again now? Because something changed. Not in remote work itself, but in how we build software. And these changes make remote work even more relevant today than it was 4–5 years ago.

Back then, the main criticism of remote work was coordination. And honestly, it was a fair point, especially in larger companies. Software development teams were highly fragmented. Work looked something like this:

• frontend engineers waiting for backend APIs

• backend engineers waiting for infrastructure

• everyone waiting for product managers to define priorities

• QA at the end to validate everything

It was a chain of dependencies. A lot of waiting. A lot of coordination.

To be fair, this wasn’t just a remote problem. It existed in offices too. People just filled the waiting time differently:

• hallway chats

• coffee breaks

• “quick syncs” that weren’t that quick

But the underlying dynamic was the same. It was a waiting game. And when that game moved to remote setups, it made many managers uncomfortable, again, especially in larger companies with lots of middle management layers.

That’s what changed. Today, the way we build software is fundamentally different.

• Teams are smaller

• Individuals own larger chunks of work

• There are fewer handoffs

• There is less dependency on others to make progress

This is the shift towards what many call the Product Engineer, where individuals take ownership of full features and work vertically across the stack. Larger work items means more hands down work and less ticket handovers and revisions. As such, teams are smaller, meaning fewer standups, sprint plannings, etc etc.

In my teams nowadays it almost feels like we let go of the work no one enjoyed, and are essentially working on building products, which is in fact what has always mattered the most.

Large Language Models and the whole set of AI tools built around them are a big driver of this change. When you combine spec-driven development with stronger ownership per individual, you eliminate a lot of the coordination overhead. And as a result there is less waiting, fewer blockers and faster iteration cycles.

This creates the perfect conditions for remote work. Because the main argument against remote work was coordination. And coordination is no longer the dominant constraint.

In this new setup, remote is not just “good enough”. It’s actually better in most cases. You can:

• work deeply without interruptions

• spend time thinking and designing systems

• interact with your AI tools and agents by voice without bothering people in an open floor office

You can lock in for a full day and ship something meaningful. Not a couple of tickets, a full feature. Sometimes a full product.

That’s a very different world from a few years ago. And it’s the world I operate in today. As a Fractional CTO in early stage startups, I work with non-technical Founders, which means that I have the broad responsibility of translating their business idea into a product spec, and then turning that spec into a product that can be used by clients who’ll pay for it. As such I spend most of my time talking with Founders and clients, writing specs and interacting with my AI tools and colleagues to review output of coding agents to push the product live.

There’s much less time spent in coordinating large teams, like I did in the past, and this current work flow fits perfectly in a remote setup.

If you zoom out, the implication is clear. The people who benefit the most from this shift are:

• high-agency individuals

• people who can operate across the stack

• people who understand both product and engineering

Remote work amplifies their leverage.

This is not about “remote vs office” as a lifestyle debate. It’s about fit to the work flow. The new way of building software:

• requires less coordination

• rewards ownership

• and favors deep, uninterrupted work

Remote just fits this model better than commuting to a noisy open floor office, in my opinion.

If you’re an engineer reading this, sitting in your work-from-home environment, and wondering what it means for you. Well, our software engineering industry is changing. While the demand for software builders is increasing, the model in which those builders are hired is steering towards outcome-driven engagements, as opposed to traditional full time jobs or hourly freelances.

The demand is shifting towards engineers who:

• can work across the stack

• understand the business

• and own outcomes

I called those Product Engineers in a recent newsletter, and many in the industry are also using this term, as in a mix between Product Manager and Software Engineer.

This is also the exact way of working I’ve been teaching recently.

In a few weeks, I’ll be running a cohort-based course with my friends at GenAI Works. It’s called Ship Reliable Software Faster with AI, and I’ll break down my Spec-Driven Development process step by step, from idea to production, and how to use AI without creating chaos.

Finally, I’m seeing more demand than I can personally handle, and I’ve been playing with some delegation models where I expand these opportunities to CTOs and Engineers around me. If you’re a Product Engineer, AI Engineer, or CTO working in this space, and you’re interested in these types of opportunities, reach out to me at sp@sergiopereira.io.

I’m happy to connect and potentially send work your way.

See you next Friday,
Sergio Pereira

Last week I wrote about the kind of opportunities that I’m seeing increased demand for, in my daily work with Startups, as a Fractional CTO.

I work every day with Startup Founders, but many readers don’t. So today I want to walk you all through this shift from their perspective, the Startup Founder’s perspective, so that everyone understands what’s going on and why these opportunities are growing in the first place.

Even if you’re not a Founder, imagine this:

• You’re starting a business from scratch, you’re founding a Startup today.

You’re doing it now, in 2026, but let me draw you a clear before and after picture, because starting a business in 2026 is fundamentally different from doing it just 5 years ago.

A few years ago, the playbook was very clear. If you wanted to build a product, you needed:

• a team of engineers

• several months of work

• and a meaningful amount of capital upfront to pay for the above

So most founders would:

• raise a seed round of funding first, the biggest dependency

• hire a team, now that they had money to pay salaries

• build the product for months, because LLMs and AI tools still didn’t exist

• and only then launch something to the market

Building software was expensive, slow, and gated behind capital. Founding a startup back then was a big test of resilience, and the focus of the Founder wasn’t product or clients upfront, in most cases it was investors, since a failure to raise enough seed funding would block everything else and collapse the Startup plans very early on.

That’s no longer true. Today, a Startup Founder can go much further on their own, even a non-technical Founder. With tools like Lovable, Claude Code, and even just ChatGPT, you can:

• prototype your product in days

• talk to users early

• iterate quickly based on feedback

• and in many cases, even generate your first revenue

You don’t need a team to get started anymore. You can build something that looks and feels like a real product, incredibly fast. That’s the shift, this wasn’t possible just 5 years ago. Now it is.

Take this as the first note, I no longer see Founders obsessed with chasing investors. I do see them obsessed with their product, showing it to clients, and iterating until they get some traction. I like it much more this way.

But there’s a catch. Prototypes are easy to build. Robust and scalable software products are not.

At some point, things get serious. You start getting traction:

• users sign up

• clients show interest

• revenue starts coming in

And that’s where the cracks show up in the product. Let me make it very concrete with actual cases I caught in my work as a Fractional CTO.

If you’re building product in a regulated space, like Fintech or Healthcare, a small mistake can be fatal:

• a misconfigured file system that allows unauthorised access to sensitive data

• insecure handling of sensitive data that allows leaks

• missing access controls that let user A access data from user B

One of those things, and you’re dealing with legal exposure that can shut your business down instantly.

If you’re building a B2C product and your go-to-market works:

• you get thousands of users at once

• your backend doesn’t scale accordingly, and your app goes down

You lose trust on day one, which is very hard to recover from.

If you’re building a B2B product:

• you land your first big client, and you’ll onboard them

• your onboarding is manual and clunky, the client people notice you’re early

• or the data isn’t properly isolated between tenants, trust erodes

You don’t just lose revenue, you lose credibility in the market you wanted to conquer.

None of these problems are visible in a prototype that you demo around. They only show up when:

• the product is under load

• edge cases are hit

• real users interact with your product

And the root cause is almost always the same: The system was never properly architected or engineered for production.

This is where my role typically comes in.

I work with early-stage founders as their technical right hand, helping them take something that already exists, a prototype, an MVP, or even just an idea, and turn it into a product that can actually support a growing business.

First off, I help non-technical Founders define clearly:

• what should happen

• in which scenarios

• with which constraints

• and what should happen when things go wrong

We make that explicit before building. Only then I start implementing (or fixing) the product.

As I described last week, this is what I call spec-driven development. You can think of it as a structured way of defining how your product behaves, before writing the code.

The goal is simple: Not just to make the product work, but to make it predictable.

When done properly, this approach:

• reduces ambiguity

• avoids hidden edge cases

• and allows you to build much faster with AI

Because the system is clearly defined. The result is that you can build production-ready software in a fraction of the time and with a fraction of the cost. Compared to just a few years ago.

And this brings us back to the economics.

Before:

• you needed a team

• you needed months

• you needed capital upfront

Now:

• you can prototype on your own

• you can validate early

• you can go further before raising money

However, the moment your product starts to matter, you need to bring in technical depth.

Not necessarily a full team. But someone who can:

• structure the system properly

• architect how it should be implemented

• and make sure it can scale without breaking

That’s the difference between a demo and a real product.

Think of it again. For a Startup Founder, this is a massive opportunity. You can move faster than ever, you can bootstrap longer, you can get real market signal before making big investments. Just be aware of where the limits are and what to do when you reach them.

And if you’re a Software Engineer reading this, and fearing that this techtonic shift in software economics might hurt your employment. Don’t worry. This shift doesn’t reduce demand for engineers, it just changes what is valuable.

Lower barriers to building software mean:

• more startups

• more products

• more experiments

All of that needs Software Engineers, however the role is evolving. Teams are smaller, but expectations on the individual are higher than they used to be.

The demand is moving away from narrow specialists and towards engineers who can:

• work across the stack

• understand the business

• and own outcomes

What many now call the “Product Engineer”.

And interestingly, many of the opportunities I’m seeing are no longer traditional full-time roles. As I explained last week, they’re fixed-scope projects and outcome-driven engagements. Which can be a great way to get exposure, build trust, and grow into larger roles.

This is exactly the process I’ll be teaching in a few weeks with my friends at GenAI Works. I’ll run a cohort-based course where I break this down my Spec-Driven Development process step by step, from idea to production, and how to use AI without creating chaos. It’s called Ship Reliable Software Faster with AI.

Finally, I’m seeing more demand than I can personally handle. If you’re a Product Engineer, AI Engineer, or CTO working in this space, and you’re interested in these types of opportunities, reach out to me at sp@sergiopereira.io. I’m happy to connect and potentially send work your way.

See you next Friday,
Sergio Pereira

Last week I wrote about the difference between vibe coding and spec-driven development, and why most AI-built products work in demos but break in production.

This week, I want to share something I’m seeing on the ground.

As a fractional CTO, I get a front-row seat to where Startup Founders and Business Owners are deploying their budgets right now. And there’s been a clear shift.

A disproportionate amount of opportunities are no longer:

• hourly work

• retainers

• full-time hires

Instead, they look like:

• “Build me an MVP”

• “Fix this broken product”

• “Get this feature into production”

• or even just “Get me a roadmap to integrate AI in my business”

Fixed scope, outcome-driven, very concrete.

I’ve done this CTO work with early stage startups for over a decade now, and I’ve gone through different phases and hype cycles. For several years my scopes of work would be heavy in hiring and managing (the hands-off phase of my career). Then a blend of hiring small teams and shipping product (the hands on-and-off flow). Now it’s clearly hands on again, even as I hire a team around me I’m shipping code on a daily basis.

The clear change is LLMs and having this AI-assisted development process, that’s so much more efficient than the old way of writing code by hand.

That’s to say that just a couple years ago, I would have passed on most of these fixed scope opportunities. Dev agencies would grab them for the lowest budget (I’d come after to clean up the mess and hire the in-house team).

So, I wasn’t rejecting these opportunities because they weren’t interesting, but because they were heavy on my time. Building an MVP properly meant:

• a lot of coding

• a lot of back and forth

• a lot of time

And fixing a broken product? Even worse. I’d be stepping into messy code, unclear requirements, unknown edge cases. It’s hard to scope, hard to price, and usually becomes a time sink. Well, in a sense “fixing broken products” still is a time sink, since the code itself tends to not be the worst part.

But building MVPs, or new products inside larger orgs, that’s quite easy to do these days. It’s not longer so heavy on my time, and more importantly with a spec-driven approach, these projects became much more deterministic when I accept them.

Now, a typical engagement looks like this:

• I spend time upfront understanding the problem

• I define the workflows and the system behavior

• I write a proper spec (inputs, outputs, rules, edge cases) - usually a distillation of meeting transcripts

• I use Cursor and Claude Code to implement it

• I test against the spec with the client, and that’s it

The coding part, which used to take most of the time, is now often the easiest step. The heavy lifting is in the thinking.

This unlocks something interesting. Projects that used to take weeks (or even months) of engineering effort can now be scoped and delivered much faster. Which means I can take on more of them, and more interestingly, I can be much more outcome-oriented, which I personally like. I can take early equity into client’s startups, or rev share, or simply a traditional fixed price project that unlocks the next stage where I can join as a proper Fractional CTO.

Plus, it’s way more fun to build products now than it used to be. For me, of course. I know many people feel the opposite way, that the craftsmanship is gone now that AI writes the actual code. Different people, different vibes, of course. I’m an optimist, and I tend to see opportunity instead of risk, and change tends to feel bright to me. Take it with the usual grain of salt, everything here is my personal view.

Regardless of feelings, these fixed-scope projects are a perfect entry point to work with Startups (and probably also with larger companies too, however I’m yet to fully tap into those). Most of the Founders I work with are non-technical. They don’t want to hire a full team immediately, most often they don’t yet have the budget to do it. And even if they do, they don’t want to commit to a long-term engagement without trust.

But they do have a clear need: build a software product that supports their business goals. Once I deliver on that quickly and reliably, I build trust. And that’s where the real opportunity is.

Because after that initial project, the conversation usually shifts to:

• “I landed a couple big clients, can you help me make it scalable?”

• “Can you help me hire a team to build the next phase?”

• “Can you stay involved as a Fractional CTO as the business grows?”

That’s the ideal outcome for everyone. The founder gets a trusted partner. The product gets built properly. And I move into a longer-term role where I can have real impact.

None of this works without a process. If you approach these projects with a vibe coding mindset, you’ll struggle:

• unclear scope

• unpredictable timelines

• fragile systems

Spec-driven development is what makes this viable. It allows you to:

• define scope clearly

• control behavior

• use AI effectively

• deliver reliably

And that’s exactly what these opportunities require.

This is exactly what I’ll be teaching in a few weeks. My friends at GenAI Works invited me to lecture a cohort-based course where I break this down step by step, and I accepted.

It’s called Ship Reliable Software Faster with AI and I go through the full Spec-Driven Development process, from idea to production, focusing on how to use AI without creating chaos, and how to structure software systems so they behave reliably.

Finally, I’m seeing more demand than I can personally handle, which is obviously a great problem to have. However, many of these opportunities are not exactly full time jobs, instead these are freelance-y gigs and fixed scope projects.

If you’re a Product Engineer, AI Engineer, or CTO working in this space, and you’re interested in this type of work, reach out to me at sp@sergiopereira.io.

I’m happy to connect and potentially send opportunities your way.

See you next Friday,
Sergio Pereira

Last week I wrote about how the bottleneck in software moved from writing code to deciding what to build and how to build it. That’s what’s driving the rise of the Product Engineer.

Some people have asked me, “ok great, I get the theory, but how does that work in practise?”. Indeed, I think very few Software Engineers, and especially engineering teams, have upgraded their processes to actually reap the opportunity presented to us by LLMs and all these powerful tools.

Today I’m writing about that. The difference between the so called “Vibe Coding” process and a structured production-level AI-assisted software development. And for that I’m explaining my own process, and what changed vs a few years ago.

The fact is that right now, almost all Software Engineers and teams are experimenting with AI tools, and most of them start the same way: We describe what we want to Cursor or Copilot. We iterate with prompts, and tweak until it works.

And to be fair, it does work pretty well many times. We can get to a proof of concept incredibly fast. Those urgent sales requests that used to be a nightmare, now we can ship a demo in the same day. A landing page, a feature, even a full app that looks functional at first glance can be much faster than before.

The problem is what happens next. We start testing a bit more thoroughly, and edge cases show up, the flows break. We realise the logic in inconsistent. Small changes create unexpected side effects somewhere else in the system.

And suddenly we’re in a place that feels very familiar to anyone who has tried to debug one of these “vibe coded” apps. We don’t understand what’s there, we don’t trust that code. And ultimately it’s not tools’ fault, it’s not even that the code is bad. The core issue is that the system was not well enough defined before building, and you end up with something that might be good for demos, but which is not ready for production.

AI made it very easy to build something that works once. It did not make it easy to build something that works reliably in production.

This is where the distinction becomes important.

Vibe Coding looks like this:

• We describe what we want

• We iterate with prompts

• We tweak until it works

It feels fast and intuitive. And it’s a great way to explore ideas and build proof of concept type code. However, it has those shortcomings. A diagram for Vibe Coding looks something like this:

That’s why the best Software Engineers, and especially those taking a Product Engineer approach, they take a different approach.

The emerging name for it is Spec-Driven Development, and it looks like this:

• You define the engineering standards (tech.md)

• You write down the functional requirements (several feature.md)

• Down to the detail of acceptance criteria, edge cases to be tested, etc

• You include all that (the “specs”) in the actual code repo

Then you use AI tools to write the code to implement all that. The code generated will not simply “work”. It will fulfil the functional requirements you defined plus follow the engineering standards you want (like tech stack, approach to testing, logging, etc etc). And above all, it’s deterministic. You get code that matches your specs. If something doesn’t work, you can simply review the spec, because often we forget some edge case or challenge some earlier assumption.

Looks something like this:

Both approaches can get us to a working demo, but only one reliably gets us to production-ready code. Because the difference is not speed, it’s determinism.

Vibe coding creates systems that behave probabilistically. They work most of the time, until they don’t.

Spec-driven development creates systems that behave deterministically. You know what should happen for a given input, and you can verify that it does.

Once you see Software Development this way, it becomes hard to unsee. And that’s also why the best Product Engineers don’t just prompt, they spend most of their time thinking, defining and constraining the system before any code is written.

That’s where the leverage is now. If that job is properly done, writing the code can nowadays be 100% written by AI, regardless of the actual tool (Cursor, Copilot, Codex, Claude Code, etc) as long as you use one of the latest models, such as Claude Opus 4.6.

My own development workflow changed a lot because of this. A few years ago, I would start coding early. I’d get a rough idea of the feature, start coding, and figure out edge cases along the way. The fact that teams are usually broken into product + tech as separate people/teams didn’t help, since the Engineers (myself and my teams included) didn’t always fully understand the functional requirements written in a ticket. Starting and figuring out edge cases along the way was actually needed to gain that context and understanding to a point where we could challenge assumptions and even spot mistakes in those functional requirements.

The process was broken, and in most teams it was not a fault of the individual Engineers, but rather a by-product of orgs that were designed around the key constraint that transforming a ticket into a pull request took most of the time in a software development life cycle. I’m certainly to blame for such decisions in the past, I reckon that my process wasn’t optimal.

However, writing code is no longer the bottleneck. So today that approach is silly, especially because most people are using AI tools to code anyway. And we’ve all tried to debug a vibe-coded app, and it’s not fun. We’re chasing behavior that was never clearly defined in the first place.

So now my process is almost the opposite, I spend most of my time upfront on the spec. I start with the problem and the workflow, I try to understand what we are actually trying to achieve, not just what was initially requested. That often means going back to the business, looking at data more carefully, or simply asking better questions.

And interesting sign of the times we live in, nowadays in my engagements I always own product and tech, as one unit. In some clients I even get a “Fractional CTPO” title instead of “Fractional CTO” (“P” is for product, in case you’re wondering) to make that explicit. I guess that’s C-level version of the “Product Engineer”.

That means I have exposure to the company’s Founders, to clients/users, to my sales and marketing colleagues, to lawyers (I work a lot in fintech and healthcare, where legal boundaries for agents and human in the loop are important to not overstep), and to anyone else relevant to help me figure out what to build and how to build it.

I have meetings, chats, email threads, etc etc with those stakeholders, I look into product usage data, bug reports and whatnot. LLMs are great to help an individual crunch that much data into signal, I built my own personal tools for this, and I often spend several days circling around a feature to get all the context needed for the spec. I write the spec and iterate it as I go through that process. Inputs, outputs, rules, constraints, expected behavior, etc. I try to make it all explicit in the spec.

Once I have a solid version, I actually use an LLM to review the spec itself. I ask it to challenge assumptions, point out missing edge cases, ask questions I didn’t think of. It’s the same concept as a code review, but before any code is written.

Only after this do I move to implementation. At that point, writing the code is often the easiest part. Whether I’m using Cursor, Copilot or Claude Code, as long as I’m using one of the latest models, it’s very common to get a correct implementation in one shot, even for fairly complex features. I leave my agents producing the code through the day and over night, usually takes some hours or a full day.

Then I test. And I still review the key parts of the code to make sure it actually follows the spec I defined. The difference is that I’m no longer discovering what the system should do while I’m coding it. That work is already done.

This is the workflow I’ve been using with clients and in my own projects, and it’s also what I’ve been teaching recently. My friends at GenAI Works invited me to lecture a cohort-based course where I break this down step by step, and I accepted.

It’s called Ship Reliable Software Faster with AI and I go through the full Spec-Driven Development process, from idea to production, focusing on how to use AI without creating chaos, and how to structure software systems so they behave reliably.

They helped me make it for busy professionals, and I packed all the content into 4 hands on sessions, where you go from idea to deployed app in just a few hours, and more importantly you’ll be equipped to use this process in your job or in your startup.

Most people don’t work like this yet. Not because they’re not capable, but because the tools make it very tempting to skip the hard parts. It feels productive to jump from prompt to prompt. It feels slower to sit down and write a proper spec.

But that’s exactly where the shift is.

So, even if you don’t join my course, please start writing proper specs for the products and features you ship, but in your job and in your personal projects. It’s the simplest change you can make, and it will completely change how you build. Thank me later :)

If you’re already implementing Spec-Driven Development in your team, reach out and let me know how it is working for you, I love discussing this stuff. Drop me a DM on Linkedin.

See you next Friday,
Sergio Pereira

Last week I wrote about why I don’t believe AI is shrinking the software engineering market. If anything, it’s doing the opposite.

AI is making software cheaper to build. So we build more of it. More products, more features, more experiments. That’s Jevons Paradox playing out in real time.

But that raises a more important question:

• Who actually captures that opportunity?

If you recall from last week, when Excel came out a lot of people thought it would kill accounting jobs. And in some ways, it did. Manual bookkeeping, ledger work, all the repetitive tasks that used to require hours of human effort started disappearing.

But that wasn’t the real story. The real story was this:

• Excel didn’t just make accounting faster. It changed who could work with numbers.

Suddenly, millions of companies had their data organized. Not just stored. Usable. They could run calculations, build models, generate charts, simulate scenarios. And that unlocked something much bigger than bookkeeping.

It created entirely new roles: Financial analysts, Management consultants, Operators making data-driven decisions, etc. Roles that are now much bigger than bookkeeping ever was.

Here’s the same chart again, in case you missed it. See how the number of jobs under these “new titles” surpassed the “old titles”.

We’re making the same mistake again. Everyone is focused on whether engineers will be replaced. Very few people are looking at what’s actually happening:

• Millions of people can now build software.

Not perfectly. Not always cleanly. But enough to create real products, real features, real businesses. That’s the shift. And if these LLM-enabled tools got this good in just 2-3 years, can any of us imagine how much better they’ll be a year from now?

And just like Excel changed the nature of working with data, these AI tools are changing the nature of building software.

For years, being a great engineer meant being great at writing code. That’s no longer where the leverage is. Code used to be the scarce resource, but now it’s a much cheaper part of the system. Writing code line by line is heading in the same direction as manual bookkeeping after Excel. Still necessary in some cases, but no longer the defining skill.

The SLDC used to be:

• Understand the ticket

• Write the code

• Ship

Now it is more like:

• Frame the problem

• Write a clear spec

• Generate code with AI

• Review and iterate

• Ship

In my view, it actually expanded, since Engineers are now expected to pick up bigger chunks of work. Like a full feature instead of a ticket. Let’s say “integrate stripe payment gateway”, instead of a ticket to build a part of it, such as “expose API endpoint to pipe payment result to frontend”.

The slow part is no longer typing code. It’s deciding what to build, and making sure what gets built actually works. This changes the shape of some of the most popular career tracks in tech: Software Engineer and Product Manager. They are actually merging into one.

The old model looked like this:

• PM defines what to build

• Software Engineer builds it

There’s always been a clear separation, clear responsibilities, but also a gap. No one fully owned the outcome. It used to be a “squad”, typically led by a PM (or PO or other title variation), and composed by a few Software Engineers, Designers, etc

The new model is different, a Product Engineer:

• Defines what to build

• Decides how to build it

• Uses AI to execute

• Owns whether it actually works

It’s a full loop, and this Product Engineer resembles more a full squad from back in the day, not “just” the PM that led it. And this is the opportunity that most people are missing, just like with Excel. Back then, the focus was on what jobs would disappear. Very few people focused on the fact that suddenly, every company could operate with data.

Now, the focus is on whether AI replaces Software Engineers. Very few people are focusing on the fact that suddenly, almost anyone can build software. And especially, Software Engineers can build software faster and better than ever before, and they can (and should) focus beyond execution.

PMs gain access to execution. Engineers gain access to decision-making. The gap between the two is collapsing, and the individuals who step into that gap are the ones pulling ahead, either as Startup Founders, or as part of a team in a larger company.

Product Engineer has been growing in popularity as a job title in recent months, as well as mentions and searches online about it.

But having said all this, what does a Product Engineer actually do different from a Software Engineer?

It’s not about prompting better or knowing more tools. This is how I see the skill set to being a great Product Engineer:

1. Problem framing

Not “how do I build this?” But:

• What problem are we actually solving?

• Is this worth building in the first place?

• What’s the smallest version that creates value?

This used to sit mostly with product. Now it’s core engineering leverage.

2. Writing clear specs

AI is only as good as the instructions you give it. Vague input creates chaotic output. Clear thinking, translated into clear specs, is what controls the system. This is where most of the leverage sits now

3. Taste and judgment

AI can generate ten different approaches. Someone has to decide:

• Which one is actually good

• What is overengineered

• What will break in production

This is where experience, “product taste” and software architecture experience all compound.

4. AI-assisted execution

This is the part everyone talks about, and it does matter a lot for sure. But it’s not the real differentiator, since everyone’s using the same few tools. It’s mostly about how to handle context and how to introduce yourself as the “human in the loop”.

6. Ownership

This is the biggest shift. Instead of “I implemented what I was asked”. The new model is “I own the outcome”.

No hiding behind tickets, or pushing frontend/backend splits of work. Full ownership of a feature means full accountability for the outcome.

If you’re reading this and thinking “this sounds obvious”, you’re right. But look at how most teams actually operate. Most Software Engineers are still waiting for specs and translating tickets into code.

Tech Twitter is a bubble. It makes us think that everyone’s using the latest agentic workflow, and certainly most engineers I speak with in my courses are experimenting with these tools, but on their job the processes are mostly still the same as a few years ago.

And this is the reason why you must pay attention. If your current role is still mostly translating tickets into code, you’re being put in a position to miss out on the shift that’s happening in the industry right now.

That’s the part of the job that’s becoming commoditized, the opportunity is not there anymore. If you’re in such a situation, there’s great opportunity to introduce this new way of working, for the benefit of everyone involved: yourself, your manager, your team and your company.

This is also why I personally enjoy building more now than I did a few years ago. I spend most of my time:

• Defining new products

• Writing specs

• Reviewing code and testing products

And much less time writing code manually. The work shifted and the leverage increased. Next week, I’ll break down the exact process I use to work this way. How I go from idea → spec → AI-generated code → production, without creating chaos.

If you’re navigating this shift already, I’d love to hear how you’re approaching it. Just reply to this email or drop me a line at sp@sergiopereira.io or a Linkedin DM and I’ll be in touch. As I said last week, I’d like to bounce ideas with CTOs, Tech and Product Leaders introducing these tools and processes in their teams too.

See you next Friday,
Sergio Pereira

Since last week, I’ve moved it to Substack, and I hope you enjoy reading it here. This also signals that I’m writing it again every Friday, after a few months of hiatus to focus on my baby girl, surgery recovery and all those curve balls that life throws at us here and there.

I’ve missed you guys. For real. Writing online, on Twitter (now X), on Linkedin, and also on this newsletter for the past 3 years, has been the best career decision I could have ever made. However, at the time it felt like just another random “why not” decision.

During this period, 90% of my Fractional CTO clients came through my online content, O’Reilly invited me to lecture courses about “AI for Software Development”, and after 25k+ students I published a book on the topic (I should write a newsletter edition about this at some point, last month the Japanese translation sold almost 2000 books, and this guy from the tiny Portuguese village is still processing it)

Not today, though. Today I’ll tell you why I’m very excited to write online again.

Our industry is changing like never before in the 22 years since I learned how to code. Large language models, and the whole set of “AI tools” that have been built on top of them are transforming the Software Engineer profession (like many others).

However (and that’s why I feel I should write again!), I feel like the content I’m reading online is overly polarised:

• On one hand we have the “AI influencers” claiming that they replaced a team of 10 with Claude Code, or that their OpenClaw instance built them a SaaS product while they sleep. One is led to either believe that non-sense, or to deny the value of these tools because of that non-sense. Both are wrong takes, imo.

• On the other hand we have the the “AI bubble is about to burst” people, mostly academics or senior Engineers who deny the value of these tools and call everything “AI slop. One is led to either believe that non-sense, or to deny the shortcomings of these tools because of that non-sense. Once again, both are wrong takes, imo.

I feel there’s a lack of “grown up people” writing online about this topic. People who are both excited about the fact that we can build an MVP in a few days (vs a month or two), but also vocal about the chaos that can be created by a team of devs hitting the tab key and creating a huge pile of tech debt that someone will need to refactor.

I personally find it much more enjoyable to code in this era. I’m spending almost all my time building robust specs and skills, and then testing and reviewing output. The part sitting in the middle, the actual writing the code, that’s something I don’t touch nearly as ofter as before.

These tools boost individual productivity, but it’s hard to translate similar gains on large teams. I think there’s a lot to discuss in how these different teams are onboarding these tools.

It’s also counter-intuitive what’s happening in the industry right now, and you might get lost in the noise of people either saying that “AI will take our jobs” or saying that “you must ignore AI slop”.

It’s called the Jevons Paradox, and it says that when something becomes more efficient and cheaper to use, people end up using more of it, not less. And as a net effect, total consumption of that “thing” goes up.

Well, in 2026, the “thing” is software. AI reduces the cost per feature, so companies increase the number of features, products, and experiments. Also, the cost of Founding a startup crumbles, and a wave of new startups is being created right now.

AI makes software dramatically cheaper to build → so we build way more of it → so the total demand for software, compute, and skilled engineers increases.

And that last part matters. Software Engineering jobs are not going down, as the AI doomers have preached for a couple years. Our industry is actually starting to expand past the bottom of 2025:

If you zoom out, we’re still far from the peak market demand of 2022, so it’s not a moment for euphoria at all. But when so many people predicted an accelerated shrinking of the industry would happen, turns out the industry is actually growing after all.

And if you zoom out further to past tech inventions, you’ll find Jevons Paradox striking again and again.

Take a look at what happened 50 years ago, when ATM machines were invented, and most market analysts predicted that the Bank Teller job would disappear within a few years:

Turns out, ATM machines did indeed replace several high frequency activities of the Bank Teller job, such as checking account balance or cashing our money from the bank account, which no longer required someone going to the bank counter speaking to the human. However, banks still needed Bank Tellers for activities that couldn’t be performed at the ATM machine, such as opening a new account, changing details in the account, fixing account issues, etc.

This lowered the cost of opening new bank branches across the US, and it was actually an opportunity for banks to accelerate selling higher margin products, such as mortgages, investment, etc. This was a period of accelerated growth in the industry, and the net number of Bank Teller jobs doubled in the decades after ATMs were invented.

That’s Jevons Paradox.

Another great example happened in the 1990s, after Excel was invented. Once again, market analysts predicted that Accountant jobs would disappear as a result. Turns out, those jobs more than doubled within a couple decades. However, some jobs did get replaced, such as Bookkeeper. And what no one predicted, brand new job titles were created, such as Management Analysts or Financial Managers, and those became bigger job categories than Accountant ever was.

In the Software Engineering industry, we’re right at the moment when the “new invention” comes to market.

And the new invention right now is Large Language Models and all these AI-assisted IDEs, CLI tools, Agents, etc that we can use to perform our job better. These are fundamentally transforming how we develop software products, and equally transforming the economics of a business to invest in software.

Some people will get replaced like Bookkeepers. Others will grow like Accountants did 20 years ago. But more importantly, some people will reap whole new opportunities as new job titles and career tracks are unlocked by these changes, just like those Managers and Analysts careers reaped the opportunity of suddenly millions of companies having their numbers in order in a tool with incredibly math capabilities for the time.

I’ll write about these skills and career tracks next week. Or at least, how I see opportunity during this transformative phase of our industry.

And if you read this far, I’d like to speak with you. I want to interview fellow CTOs and Tech Leaders who are going through the process of upgrading the software development processes in their teams to reap the benefits of these powerful tools, but who are also putting the guardrails in place to avoid prod issues and downtimes.

I want to share experiences of the tools that work best, how the processes shift from coding to planning + reviewing, how if affects team roster and interview processes, what went wrong and what actually worked.

If you’re keen to bounce ideas, drop me a line at sp@sergiopereira.io or a Linkedin DM and I’ll be in touch.

It feels good to write again, and thanks everyone who messaged during my time off to check in. I’ve been building, learning, and having quite some fun with all this. It’s a pleasure to share my learnings in public again.

See you next Friday,

Sergio Pereira

After a couple years writing this newsletter on Brevo, I’ve finally moved everything to Substack.

This was long overdue.

Many of you mentioned emails landing in spam, formatting issues on mobile, and honestly the writing experience on my side wasn’t great either. I also want this newsletter to be easier to discover and grow over time, not just sit in an inbox list.

So from today onwards, Substack is the new home.

Nothing changes in terms of content:

• still free

• still weekly

• still based on what I’m actually building and learning

But the experience should be much better. You can reply directly, everything is properly archived, and it’s easier for others to find it.

For a couple weeks I’ll publish both on Substack and Brevo in case someone has trouble reading on Substack, and then I’ll fully stop the old publishing via Brevo.

Before I fully settle into this new setup, I’d love your input:

• What topics have you found most useful in past editions?

• And what topics do you wish me to write about going forward?

Reply and tell me, I’ll read every message.

If you’ve been reading for a while, you know that it started as a “remote work” newsletter.

Over time, that naturally evolved as I’m also excited about other topics.

Later this year I’m celebrating 10 years working remotely. Can you imagine a young guy from lower middle class family living in a small village in Portugal, who’s been working for US startups for a decade. And in recent years lecturing courses for people who work in some of the most well known companies on earth, which I’d only watch on TV. All this while living from the same tiny village.

I’ve always been an average boy with above average dreams. But even that boy would have chuckled at a career that is way beyond anything I could have imagined.

I’m deeply passionate about working remote and about helping people working remote. It’s been life changing for me and for many of you out there. However, I feel that writing only about remote work misses the point, because there’s multiple ways of having a remote career. And I’ve tried several:

• Having a full time remote job

• Working remote as a freelancer (or a Fractional CTO)

• Lecturing courses for international students

• Writing books for international readers

• Building software products and selling them to international clients

All of those are viable options to achieve the goal of collecting USD payments while living elsewhere on earth (or even nomading around). As such, these days I’ll mostly of what I write about:

• Working as a Fractional CTO with startups. I feel that my journey as on of the first fCTOs writing about it as a career has inspired many of you to work in non-full-time arrangements (or at least try to do it). I want to continue doing that.

• Building SaaS products myself. As I wrote last week, I’ve become a builder again, I’m proudly a hands on CTO again and I’m allocating time to ship my own B2B products and have fun trying to find clients.

• Figuring out what AI is actually changing in how software gets built. I feel like we’re going through a tectonic shift in our software industry, and I want to learn and experiment in public. There’s so much noise out there, I feel like I could be a more balanced voice who’s excited but also vigilant about this shift.

It’s less about a single topic, and more about patterns I keep seeing across companies, teams, and products, and the topics I’m excited about at each moment in this Software Engineering world.

What works. What breaks. What’s changing. And right now, things are changing fast.

If you’re new here, here’s what you can expect:

• POV lessons from building products and working with startup founders

• How small teams can ship products fast (and where they usually fail)

• What AI is actually changing in software development workflows

• Occasional thoughts on careers, freelancing, and how this industry is evolving

No fluff, just what I see working in practice.

In fact, it’s what I do on Linkedin and on X, where I write daily about these topics.

If you want to get a sense of the previous content, here are some of my favourite pieces from the old newsletter:

→ Managing my time as a remote worker
→ The growth or fixed scope work opportunities
→ My Fractional CTO career is a roller coaster
→ Is AI really stealing our jobs??
→ Are you ready to be a remote fractional Product Engineer? You should!
→ The demand for Fractional Remote employees
→ Live in the EU. Work remote for the US.
→ Side projects can boost a remote career
→ Most startups work remote, this is why
→ My first remote job

(Full archive still lives on the old site for now)

I’m excited to double down on this again.

Between the products I’ve been building, the conversations I’m having, and everything happening around AI right now, there’s a lot to write about.

See you next Friday,

Sergio Pereira