I used to introduce myself as “a Senior Angular Developer.”
Seven years of components, RxJS streams, NgModules, Signals, Nx monorepos, CI pipelines, performance audits — the whole thing.
On paper, I looked production‑ready.
Then I started building my own AI‑driven SaaS.
No corporate backend team. No DevOps department. No “someone else” handling auth, storage, or migrations.
Just me, Supabase, Stripe, AI integrations… and a lot of gaps I didn’t know I had.
Suddenly it became painfully obvious:
I know how to operate Angular.
I don’t really know the web — and it’s actively blocking me.
My AI SaaS Forced Me to Wear a Backend Hat
On client projects, there’s always a safety net.
You have a backend squad, a DevOps person, maybe a database architect. I could stay in my lane: fix Angular apps generalists broke, do Component Detoxes , tame Signals, squeeze TBT and LCP, and ship features.
On my own product, there is no “lane”. It’s just reality:
- AI‑driven SaaS that needs real users ,
- real payments,
- real dashboards,
- and real‑time data.
No one else is coming to wire it together.
I picked Supabase to move fast. “Serverless Postgres with auth, storage, and real‑time built in” sounded perfect.
Except here’s what that actually meant in practice.
The Non‑Angular Concepts That Exposed Me
Here’s the exact breakdown of the non‑Angular and advanced web development concepts I had to learn/use for this project — and where the lack of them slowed me down.
1. Backend, Database, and Real‑time Infrastructure
Even though I’m not writing a custom C# or Node API, I still had to wear the Backend Developer hat.
PostgreSQL & database design
I’m using Supabase, which means:
- designing tables for things like orders, settings, s_ubscriptions_,
- deciding how relations should work,
- thinking about migrations and how to evolve the schema without breaking production.
This isn’t “just clicking in the UI”. It’s real database design.
Seven years of Angular didn’t prepare me for writing a schema that won’t bite me six months from now.
Real‑time WebSockets
In my orders.service.ts, the app subscribes to live database changes via something like:
this.supabase
.channel('public:orders')
.on('postgres_changes', { event: '*', schema: 'public', table: 'orders' }, ...)
.subscribe();
This isn’t Angular magic.
It’s WebSockets, pub/sub, and real‑time event streams.
To use it well, you need to understand:
- how channels work,
- what happens when the network drops,
- how to avoid memory leaks and duplicate subscriptions,
- how to reconcile real‑time updates with local state.
Angular gives me Observables. Supabase gives me events.
But thinking through real‑time architecture? That’s on me.
Cloud storage
I’m handling file uploads (car photos, documents) to Supabase Storage buckets:
- dealing with signed URLs,
- thinking about public vs private buckets,
- handling failures and retries,
- understanding multipart form data and file sizes.
Again: none of this lives in angular/core.
It’s just the web.
Authentication & Row Level Security
Securing the database isn’t just “turn on auth”.
I’m writing PostgreSQL RLS policies so malicious users can’t:
- query other people’s data,
- bypass my frontend checks,
- abuse the public endpoints.
That’s real backend security.
Angular can’t save you if your policies are wrong.
The Hard Truth: I Only Know Angular
Here’s the part I’m not proud of:
I only know Angular.
That’s it. No React, no Svelte, no mobile, no real backend stack.
Seven years in and I basically have one tool.
It’s a powerful tool. I’ve done serious work with it.
But it’s still one tool.
It didn’t really matter when I was:
- embedded in big teams,
- focused on one side of the stack,
- operating inside someone else’s architecture.
It matters a lot when:
- I’m building my own product,
- I’m responsible for the entire experience,
- there is no “backend team” to blame.
Right now, my own lack of broader web skills is a bottleneck in my own company.
And that’s a stupid place to be.
Even My Own Ecosystem Is Pushing Me Out
There’s another uncomfortable trend: Angular freelance opportunities are just fewer.
And the ones that do show up often look like this:
- “Angular + .NET”
- “Angular + Java Spring”
- “Full‑stack Angular dev (C#, SQL)”
That’s not where I want to go. I don’t want to become a .NET or Java backend engineer just to keep using the one framework I know.
So even inside my own ecosystem, the market is basically saying:
Being very good at just Angular isn’t enough anymore.
Bring backend, mobile, or something else to the table.
At the same time, I’ve just started my own solo company:
- building AI‑driven SaaS ,
- offering automation consulting.
Both of those need:
- web that isn’t always Angular,
- mobile that definitely isn’t Angular.
Right now, I can’t do either outside of Angular without a fight.
That’s not a nice‑to‑have problem anymore. That’s a strategy risk.
I’m Not Ditching AI Tools — I’m Changing How I Use Them
There’s one more twist.
I use Claude Code and Antigravity heavily. And I’m going to keep using them.
They’re not the problem. In fact, they’re the reason I can:
- move fast with Supabase,
- scaffold endpoints,
- debug RLS policies,
- sketch non‑Angular architecture without spending months reading docs.
The problem is who’s driving.
There are two ways to use tools like Claude Code:
As the primary brain :
— “Write the schema for me.”
— “Design the RLS policies.”
— “Give me a Supabase + Angular architecture.”
You accept what it outputs, maybe tweak a bit, and move on.As a turbocharger for your own thinking :
— You decide on the shape of the schema,
— you define the security model,
— you outline the architecture…
Then you ask the tool to implement, optimize, or challenge your idea.
Right now, in pure Angular land, I’m in group 2.
I know what “good” looks like. I use the tools to get there faster.
Outside Angular? I can feel myself slipping into group 1.
That’s dangerous.
I don’t want to be the founder who outsources the core architecture of his own SaaS to a chatbot.
What “Fixing My Stack” Actually Means
So when I say I want to “fix my stack fast”, I don’t mean:
- memorizing every CSS property manually,
- hand‑coding everything from scratch without help,
- pretending I don’t have AI in my toolbox.
I mean something much more specific:
I want to understand web and backend fundamentals well enough
that Claude Code and Antigravity are implementation accelerators ,
not architecture substitutes.
Concretely, that means:
1. Owning my Supabase architecture
- Designing tables and relations myself, then asking Claude to sanity‑check.
- Writing my own RLS policies first, then asking the tool to fuzz them for edge cases.
- Being able to explain why a real‑time channel is wired in a certain way, not just “because the docs said so.”
2. Treating frontend as “web”, not “only Angular”
- Building some flows without Angular at all, just to refresh my mental model of the DOM and browser APIs.
- Understanding what the browser is doing before Angular boots.
- Caring about semantic HTML, accessibility, and CSS performance as much as I care about Signals and change detection.
3. Adding at least one non‑Angular delivery surface
My AI SaaS and automation consulting both need:
- a marketing site,
- a simple dashboard,
- probably a mobile touchpoint at some point.
They don’t all need Angular.
I don’t need to become a React influencer overnight.
But I do need to be able to say:
- “This one is better as a minimal, framework‑less page.”
- “This one can be a simple React/Next client.”
- “This is the part Angular is actually good for.”
4. Using AI to test my understanding, not replace it
For example:
- I design a schema → ask Claude Code: “Where will this break in 6 months?”
- I write a security policy → ask it to “think like an attacker and break it.”
- I sketch a simple SPA without Angular → ask it to critique my state handling.
If I can’t independently evaluate the feedback, that’s a red flag.
That’s the gap I need to close.
Senior Means Being Bigger Than Your Framework
I still fix the Angular apps generalists break.
I still offer surgical Angular interventions as micro‑engagements.
I still like being the person you call when your 500‑line component is blocking an entire release.
But building my own AI‑driven SaaS forced me to admit something:
I became a senior operator of a single framework.
I didn’t become a senior web developer.
Seven years of Angular got me very far.
It paid well. It built my reputation. It opened doors.
Now it’s also the thing that can quietly cap my upside if I let it.
So this is the reboot:
- keep Angular as my sharpest tool ,
- rebuild my foundation as an actual web developer,
- use Claude Code and Antigravity as force multipliers , not autopilots,
- and make sure my own product doesn’t get blocked by the limits of my comfort zone.
If you’ve spent years living inside one framework, this isn’t an accusation.
It’s a status report from someone in the same position.
Your turn:
What part of your stack is quietly bottlenecking you — and are you driving your tools, or are they driving you?
I fix the Angular apps that generalists break.
Karol Modelski is a senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.
If your Angular app is slowing your team down, start here: https://www.karol-modelski.scale-sail.io/
Top comments (0)