A Series: Building a SaaS with AI as my teammate
Over the last few years, I've worked on engineering teams where features rarely started with code.
They started with conversations.
A Product Manager would present a problem or feature idea. Engineers would discuss the technical approach, identify risks, challenge assumptions, estimate the work, and agree on the scope. Once everyone aligned, we'd break the work down into issues, implement the solution, open a Pull Request, review it, merge it, and finally close the issue.
Every team I've worked with had its own way of documenting issues and Pull Requests. Some were more structured than others (and yes, sometimes we'd just write the bare minimum 😅). But one thing stayed consistent: there was always a process behind the code.
Then I started building my own SaaS.
Suddenly I was wearing every hat.
- Product Manager
- Software Engineer
- Tech Lead
- QA Engineer
- Reviewer
Around the same time, I started experimenting with Cursor.
Like many people, my first instinct was to use it as a coding assistant.
"Build this feature."
And honestly... it worked.
Cursor generated code surprisingly well.
But after a while, something felt off.
The code appeared.
The engineering process disappeared.
There were no planning discussions.
No issue breakdown.
No implementation plan.
No clear commit boundaries.
No Pull Request summary.
No reviewer checklist.
It was skipping everything that I had learned from working on software teams.
That's when I realized something.
I wasn't missing a better AI model.
I was missing the team process.
Instead of asking Cursor to simply build features, I started teaching it how my team used to work.
Rather than saying:
Build Google Authentication.
I asked it to:
- propose a GitHub Issue
- define the scope
- describe what is included and excluded
- suggest a feature branch
- create an implementation plan
- identify logical commit boundaries
- pause before making large changes
- generate a Pull Request description
- include a reviewer checklist
- document architectural decisions
The difference was immediate.
Cursor stopped feeling like a code generator.
It started feeling like another engineer on the team.
Not because it suddenly became smarter, but because I finally gave it the same context and expectations I'd give a teammate.
Before vs. After
Before
Idea → Prompt Cursor → AI writes code → Commit → Done
I used to just plainly give instructions to AI to build the idea and review the code. If I instruct it to build a whole feature, it spits out a whole chunk of code where I will have to figure out everything on my own. 😅 If I think about using this in production, then it is out of the question. 🙅♀️
Now
Idea → Refine the problem → GitHub Issue → Discuss scope → Feature branch → Implementation plan → Small logical commits → Tests → Pull Request → Reviewer checklist → Review → Merge
It looks surprisingly similar to how many engineering teams already work.
The difference is that I'm now doing it as a solo developer with AI helping me execute the process. This is much easier for me to refine the scope, reviewing the code and making changes.
Examples from my project
Once I had this workflow in place, every feature followed the same lifecycle.
Instead of jumping directly into implementation, Cursor first generated an issue describing the feature, the expected behaviour, and the boundaries of the work.
During implementation, I instructed Cursor to stop at logical milestones and recommend commit boundaries instead of producing one massive commit.
Finally, before merging, Cursor generated a Pull Request summary, documented the architectural decisions, and produced a checklist that I could use during review.
What changed?
Something unexpected happened.
The better my engineering process became...
...the better Cursor became.
Not because the model improved.
Because my instructions improved.
I wasn't asking Cursor to write code anymore.
I was teaching it how I wanted software to be built.
That also changed the quality of the output.
The implementation became easier to review because every change already had context.
The commit history became much cleaner because features were naturally broken into smaller pieces.
The Pull Requests became easier to understand because they explained not only what changed, but why.
What AI isn't replacing
One thing I want to be careful about is the narrative around AI replacing roles.
This workflow isn't replacing Product Managers, QA Engineers, or Software Engineers.
It's helping automate the repetitive parts of the engineering process.
The AI can help draft issues, suggest implementation plans, generate Pull Request descriptions, and create reviewer checklists.
But I still decide:
- what problem we're solving
- the priorities
- the scope
- the architecture
- the trade-offs
- whether the implementation is acceptable
The judgement is still mine.
The AI simply helps me execute the process more consistently.
What's next?
This is still very much an experiment.
I'm continuously refining the workflow as I build my SaaS, and I'm learning something new with almost every feature.
Top comments (2)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.