You know the one. The one with the blinking cursor in the other tab. The one typing faster than both of us combined.

The candidate pretends they are not using it. I pretend I believe them. We both pretend this is a meaningful signal about whether they can ship a feature without setting the build pipeline on fire. Everybody leaves the call feeling vaguely unclean. Ten out of ten, no notes, would not recommend to a friend.

Except I do have notes. A lot of them. I also have opinions, because I have been stewing on this all afternoon and the coffee has not helped. So here we are. This post is for two people: the person who has to run the interview and does not know where to point the flashlight anymore, and the person on the other end of that call who read three LinkedIn threads about “how to beat AI-powered interviews” and somehow came out more confused than they went in. Both of you are going to get roasted, gently. It is for your own good.

The CV that ChatGPT wrote and nobody proofread

Let us start before the call even happens. Let us start with the CV.

For about a year now I have been seeing documents that look less like CVs and more like character sheets from a game I never agreed to play. “React 85%. Angular 90%. TypeScript 80%. Node 75%.” Clean, round, symmetrical, suspiciously confident, all suspiciously ending in five or zero as if the candidate’s skills were rounded for cashier convenience. It is the kind of precision nobody in the history of software has ever felt about their own abilities. I have been doing frontend for nearly two decades and I still could not tell you whether I am “87% Angular” or “63% Angular” or just “a guy who mostly remembers where the semicolons go and when to stop arguing about tabs.”

Nobody writes about themselves in percentages. It is not how humans self-assess. It is, however, exactly how an LLM fills in a table when you politely ask it to “make my CV look more professional.” And the LLM, bless it, does exactly what you asked, with the quiet competence of a kid who really wants that gold star.

And I am not alone in noticing. The numbers on this are actually pretty stark: around two-thirds of job candidates now use AI somewhere in their application process, 90% of hiring managers report a spike in low-effort spammy applications, and 78% of companies actively check for AI-generated content. One Resume Now survey of 925 HR workers found that 62% of hiring managers say AI-generated resumes without personalization lead to rejections. So when I tell you “I can smell an AI-written CV from orbit,” I am not being dramatic, I am describing the average Tuesday for anyone doing frontend hiring in 2026.

To be completely clear: I am a huge fan of numbers on a CV. I love a good SMART bullet point. “Cut cold start from 2.1s to 380ms on the pricing page.” “Migrated 140 components from AngularJS to Angular 17 over eight months.” “Replaced our home-grown form library with Reactive Forms and removed 4,000 lines of dead code.” These are gorgeous. I want to hear the story behind every single one. Give me more of those.

What breaks the spell is not the presence of numbers. It is the too-good-to-be-true energy of the whole document. You know the vibe:

“Increased application performance by 47%.”

“Improved conversion rate by 23%.”

“Contributed to revenue growth of 3.5M.”

“Reduced bundle size by 61% and improved user retention by 18%.”

Four bullets. Every one a banger. No context, no baseline, no attribution, no “we tried three things and this was the one that worked.” Just a highlight reel of round numbers that all happen to land on the good side of zero. It reads less like a career and more like a pitch deck that an LLM generated after being asked to “make it sound impactful.”

This is not a trap question. It is honestly not even the candidate’s fault half the time, because the resume-builder tool literally prompted them with “add measurable impact here.” But the second you ask “walk me through the 18% retention number, what was the baseline, what was the measurement window, what else changed in that sprint, who owned that metric”, one of two things happens. Either a real story unfolds (and you relax, because the candidate was just over-polishing something real) or the whole thing deflates in about fifteen seconds. Both outcomes are useful. That is the point.

The tell, again, is not the numbers themselves. It is the pattern. When every single bullet sparkles and not one of them admits a trade-off, a failure, a “it worked but we spent three weeks on the wrong thing first”, what you are reading is not a career summary. It is a rendered document, and the person who rendered it may not even remember what went in. That is the thing to probe.

What I actually look for in a CV now:

• Projects described as projects, not as a vague cloud of “modern frameworks and best practices”

• Technologies attached to actual work, not floating in a separate Skills section like product labels in a supermarket

• Numbers that mean something (”cut initial render from 2.1s to 380ms”, “migrated 140 components from AngularJS to Angular 17 over eight months”) instead of numbers that mean nothing (”JavaScript 92%, soft skills 88%”)

• The ability to expand every single bullet into a five-minute story. Because if you cannot, it is not your CV. It is a CV-shaped object that arrived in your inbox.

That last one is the only real rule. The CV is not a document, it is a contract for the first 30 minutes of our conversation. Everything on it is fair game. If a line is too dangerous to defend, take it out before you hit send. Radical concept, I know.

“Is the candidate cheating?” Wrong question.

Now the elephant. Remote interviews. Second monitor. Cursor open in the background. Claude whispering sweet nothings into a hidden Airpod. The whole pantomime.

Here is my confession. I used to care about this a lot. Like, embarrassingly a lot. The instinct is to build traps. Stricter challenges, trickier questions, increasingly baroque live-coding exercises, the whole interrogation kit. At my lowest point I was basically one step away from asking candidates to solve a LeetCode hard while balancing a glass of water on their head, just to prove they were really there. It does not work. It is miserable for everyone including me, good cheaters are still good at cheating, bad cheaters fail anyway, and at some point you catch your own reflection in the webcam during a 45-minute technical screen and realise you have become a TSA agent with a subscription to Pluralsight. Not a great look.

So I dropped it. Not because I stopped caring, but because I was asking the wrong question. The real question is not “how do I stop the candidate from using AI?” It is:

Why am I asking anything that AI answers better than a human in the first place?

Because if your interview question can be solved by a well-prompted LLM in three seconds, congratulations, you have just verified that your candidate knows how to type into a text box. That is a skill. It is just not the skill you are hiring for. Probably.

“What is a closure?” AI wins. “Explain useEffect.” AI wins. “Difference between let, const, and var?” AI wins, and also I am going to bed.

These were great questions in 2015 when Google was the cheat code and we all pretended it was not. They are now the equivalent of asking a driver to recite the dictionary definition of “steering wheel.”

So I moved the whole interview somewhere the model cannot follow.

Interview the human, not the stack

The questions that work now (and work precisely because they are AI-proof, not by accident but by design) go something like this:

• “Tell me about the worst bug you shipped in the last year. What was it, how did you find it, and what did you change so it would not happen again?”

• “Describe a moment when you knew your team was making a bad architectural call, and you let it happen anyway. Why? What would you do differently today?”

• “Tell me about a technical decision you are proud of. Now tell me about one you regret.”

• “What is the hardest code review you have ever given or received? Not technically hard, emotionally hard.”

• “When did you last change your mind about a pattern or a practice you used to defend? What convinced you?”

None of these can be prompted. Not because they are clever, but because the answer requires specific humans, specific code, specific hallway conversations, specific 2 a.m. Slack messages. You can try to bluff, but you cannot get past the third follow-up question. There is always a third follow-up question. That is the trick. It is not a magic trick. It is just “keep asking ‘and then what’” until either a real memory surfaces or the whole thing collapses.

And here is the counterintuitive bit. The candidates I trust most are the ones who get things wrong in a very specific, human way. The ones who say “actually, I thought X for years and then I got bitten by it.” The ones who hesitate, reconsider, correct themselves. That hesitation is the sound of someone who has actually been in the room. Candidates who answer everything smoothly and confidently usually fall into one of two buckets: they have an earpiece, or they have never shipped anything that hurt them. I do not know which is worse.

Actually I do. The second one is worse. The first one at least owns a microphone.

Trade-offs, opinions, and the dying art of having a take

I still ask about patterns. I just do not ask what they are. I ask when you would not use them.

• “When are Angular signals actually better than RxJS, and when are they worse? Give me a concrete example of each.”

• “Page-Feature Composition vs. classic smart/dumb components: where does PFC give you leverage, and where does it fall apart?”

• “OnPush, trackBy, defer, lazy loading. Which of these actually move TTI, and which are just code hygiene pretending to be performance?”

• “Last project where you consciously chose NOT to use a state management library even though there was state. Walk me through the reasoning.”

I am not looking for correct answers. I am looking for an opinion that the candidate can defend without outsourcing. They can disagree with me. I want them to disagree with me. What I cannot work with is the verbal equivalent of a shrug wrapped in jargon. “It depends” is not an opinion, it is a survival strategy, and I am running out of patience for it.

The developers I want on my team have taste. Taste is the one thing the model cannot give them. It also happens to be the first thing that atrophies when you let the model drive every decision.

The AI literacy test: not how you use it, why you think it works

This is where it gets fun. I ask every candidate about AI now. Not to catch them, but to find out how deeply they actually understand the thing they are putting in their workflow.

Because I see two failure modes, and honestly both of them keep me up at night in different ways.

Type 1: The Dabbler. Uses ChatGPT “sometimes, for small things.” Does not know which model is behind the chat. Has not heard of context windows. Genuinely thinks MCP stands for something Marvel-adjacent. For the Dabbler, AI is “a slightly faster Stack Overflow” and any attempt to discuss agents, tool use, or RAG produces the facial expression of someone being handed a wine list in a language they do not speak. A year from now the Dabbler will be lapped by anyone who took this seriously, and they will not even notice until a junior colleague reviews their PR and politely asks why they are still writing boilerplate by hand like it is 2022.

Type 2: The Full Vibe Coder. Oh buddy. If you know, you know, and if you do not, I already wrote a whole post about this one called Stop Vibing, Start Understanding, where I got most of the yelling out of my system, so I will try to be brief here. The Vibe Coder prompts “build me a login component” and accepts whatever falls out of the machine like a gumball from a supermarket dispenser. They are fast. Terrifyingly fast. Right up until something breaks, at which point they stare at their own codebase with the haunted expression of a person trying to read Linear A after a long weekend, because they did not actually write the code, they commissioned it, and you cannot debug a commission. They are a load-bearing incident waiting to happen. The incident will happen on a Friday. It is always a Friday. I do not make the rules.

Both of these people will tell you, with total sincerity and zero self-awareness, that they “use AI a lot.” Both are wrong in opposite directions. Neither is who you want on call at 2 a.m. when the error dashboard turns the colour of a traffic cone.

The candidate I want sits in the middle and sounds like this:

• “Yeah, my AI hallucinates sometimes. Here is how I usually catch it.”

• “I keep my prompts short because I know the model loses track past a certain context length, and I would rather feed it one focused chunk than my whole repo.”

• “I let it write boilerplate and unit tests. I do not let it near anything security-adjacent without reading every line.”

• “The other day Claude confidently invented a method on RxJS that does not exist. I only caught it because the types screamed. If I had been vibe coding, that would have shipped.”

• “I use Cursor for inline, Claude Code for bigger refactors, and I keep a list of things I never delegate. Yes, I have thought about this.”

I do not need a lecture on transformer architecture. I need operational understanding. The same way I expect a frontend dev to know roughly what the event loop is doing without having read the V8 source code. Curious people ask themselves these questions unprompted. Incurious people treat the tool as a black box, and black boxes, as anyone who has been on-call can confirm, always explode at the worst possible moment.

If a candidate uses AI every day and cannot tell me why it sometimes lies, that is not a skill gap. That is an attitude problem. And attitude scales across a codebase faster than any framework.

The checklist, because you are going to skim anyway

Fine. Here, have it in one place:

1. The CV is theirs. Every bullet expands into a five-minute story. If it does not, it is not theirs.

2. Decisions, not definitions. “Why did you choose this” beats “what is this” every time.

3. Trade-offs with a take. “We picked X because Y, but today I would go with Z because...” That is the sound of a senior.

4. Mistakes and the lessons. No mistakes means either they are lying or they never shipped anything that mattered.

5. Tool understanding, AI included. How, why, where it breaks, what it cannot give them.

6. Thinking out loud. I give a small problem, not to see the solution but to see the path. A solution without a path is a thing the LLM produced.

7. Translation skills. “Explain this piece of your project to me like I am a PM.” Because the team is not just devs, and if you cannot talk to the people who pay you, you are a very expensive rubber duck.

If you are on the other side of the table

Okay, switching sides. Hello. Statistically, some of you reading this are the people being interviewed, not the ones doing the interviewing. This section is for you, and I am going to be a little more direct than usual, because I think the advice going around the internet right now is making things worse.

Let me start with the single most important thing, and then we will get tactical.

“I do not know” is a complete sentence

I cannot stress this enough. The strongest thing you can say on a technical interview is “I do not know, but here is how I would find out.” The second you try to ad-lib your way through a question you do not understand, everyone on the call hears it. It is obvious. It is obvious the way a bad lie from a child is obvious. And the tragedy is that the question you were bluffing through was probably something I would have happily explained, moved past, and not held against you at all.

Seniors say “I do not know” constantly. It is one of the ways you tell a senior from a mid. Juniors say “I do not know” and then apologise for 30 seconds. Mids say “well, it kind of depends on, um, several factors, and in some contexts you might consider...” until the clock runs out. Be the senior, even if you are not one yet. The shortcut is available.

Do not scheme

I know the temptation. Everybody is whispering about earpieces, second monitors, AI overlays that read the screen and feed you answers, entire YouTube tutorials on “how to pass a technical interview with Cursor in the background.” Some of it even works, for about ten minutes. Here is what you need to understand: the hiring manager on the other side has done this hundreds of times and is specifically trained to notice the smell of a bluff. You are not as subtle as you think you are. Nobody is.

But more importantly, even if it works, what have you won? A job where every day is a new test you are going to fail because you lied yourself into it. A team that thinks you are a senior when you are a junior who is great at prompting. Six months of sweating every stand-up. At some point the mask slips, and then the fall is much harder than if you had just been honest in the first hour.

The market is tight right now, and I know how it feels to need the job. I am not lecturing you. I am telling you the scheme has a worse ROI than just being yourself. Truly.

The behavioural stuff nobody writes about because it feels beneath them

These feel embarrassingly basic to even list, which is exactly why I have to list them. Nobody writes about this stuff, so everybody gets it wrong, and then they go home and blame their rejection on “the vibes.” The vibes are downstream of the basics. Here are the basics.

• Look at the camera, not at your own face. We have all been guilty of this one. Your own face is fascinating. It is right there, in the corner of the Zoom window, doing expressions you did not know it could do. But if your eyes are constantly darting sideways or down-and-to-the-right, we notice, and we notice in a very specific “is this person reading off something” way. If you need a moment to think, it is fine to look up or away briefly, the way people do in actual conversations. What sets off alarms is the rhythmic sideways scan of a person subtitling their own life in real time. Close the other tabs. Close the AI overlay you told yourself you would not actually use. You know the one. Yes, that one.

• Let silence exist. When I ask a hard question, take five seconds. Take ten. Say “give me a moment to think about that” and then actually think. I love hearing that sentence. It is the opposite of a red flag, it is basically a heart emoji. Rushing to fill silence is what gets you in trouble, because the words that come out under panic are almost always wrong, and then you have to defend them, and now you are in a bar fight with yourself over an opinion you did not even have ninety seconds ago.

• Do not memorise answers. Memorised answers have a specific cadence and we can all hear it. They sound like a LinkedIn post being read aloud by a person who used to do local radio, and nobody wants to hire a LinkedIn post. Your real experience, told messily, with detours and “wait no, that was the other project” corrections, is worth ten polished fakes. The mess is the credential.

• Disagree when you disagree. Politely, but actually disagree. If I suggest an approach and you think it is wrong, say so. This is not a trap. It is the single biggest signal that I want to work with you. The candidates I still remember years later are the ones who pushed back on something I said and were right. The ones I have already forgotten are the ones who nodded along and called everything I said “a great point.”

• Bring real questions. “What does a normal day look like” is fine, forgettable, and makes me think you downloaded a list. “What is the worst part of this codebase and why” is the kind of question that makes me want to hire you before we have even finished the call, because it is the question of a person who has already mentally moved in and is checking for damp patches. You are allowed to interview us back. You are encouraged to. If the company cannot handle being interviewed, run.

• Do not oversell AI fluency you do not have. If you have barely touched Cursor, do not pretend you live inside it like a monk in a cave. If Copilot is basically your whole AI story, say so, and then tell me what you got out of it and the one time it steered you off a cliff. Honest beats impressive every single time in this specific conversation, because I will find out in two follow-up questions either way, and the difference between “honest and learning” and “bluffing and caught” is the entire interview.

The CV and prep bit

Since we are already here:

• Read your CV out loud the day before. Every line should produce a memory, not a shrug. If a line makes you sweat, either cut it or prepare the real story behind it. You are not obligated to keep anything an AI tool put there “for impact.”

• Have two or three war stories in your pocket. Context, problem, decision you made, trade-off you accepted, outcome, what you would change. Do not recite them. Know them well enough that you can pull the relevant one out on demand when a question lands nearby. This is the thing seniors actually do that juniors think is improvisation. It is not. It is preparation that looks like improvisation.

• Know your own AI workflow, in your own words. Not “I use AI a lot.” That phrase is meaningless now. What specifically, for what, where do you not let it in, what was the last time it burned you. One minute of honest, specific answer is worth an hour of buzzwords.

• Be ready to talk about what the model cannot do. Not NeurIPS level. “Here is a time it lied to me and here is how I noticed” level. This is where you prove you are a pilot, not a passenger.

• Have opinions. Yours. Not mine, not Twitter’s, not the top answer on Stack Overflow. If I say something that genuinely lands, update your view in real time and tell me so. That is not weakness. That is the single most senior move in the entire interview.

And one last thing, which is going to sound obvious until you realise how often people skip it: be kind to yourself about the interview you just bombed. Everybody bombs them. I bomb them. The person interviewing you has bombed them. The market is brutal right now and a rejection is usually not a referendum on your worth, it is a referendum on a one-hour conversation between two tired humans on a Tuesday afternoon. Take the notes, find the one thing you want to do better next time, and move on. That is the loop. Welcome to it.

And if you are on my side of the table, one last word before we part: please, for the love of everything, stop asking questions whose answers live on the first page of a Google search. That was a decent filter in 2015 when the filter was the candidate’s memory. The memory now lives in a data centre in Virginia. You have to be the filter yourself. Sorry. That is the job now.

Wrapping up before I start ranting again

Hiring in the age of AI is not harder because candidates cheat. It is harder because almost everything we used to test for has quietly become free. Memorised APIs. Encyclopedic knowledge of Array methods. The ability to recite the Gang of Four without giggling at “Abstract Factory.” All of it, two tokens and a small monthly subscription.

The value of a candidate has moved. I wrote about this in “You’re Not a Coder Anymore. You’re a Solver” and I stand by every word: the job has shifted toward the things models are worst at. Context. Judgement. Taste. Hard-won scars. The ability to explain to a non-technical stakeholder why we are about to spend two sprints on something that, to them, “already works.” If you can read those qualities off a person in an hour, you will build a good team. If you are still opening your interviews with “what is a Promise”, you will build a team that looks great on paper and turns into a small-but-reliable fire the first time production has a bad Tuesday.

So, hiring managers: stop outsourcing the filter to questions that Google solved a decade ago and ChatGPT now solves in three seconds while also writing you a haiku about it.

Candidates: stop scheming, start saying “I do not know”, and for the love of the event loop, close the other tab. We can tell.

And everybody else: welcome to 2026, where the most important interview skill is being a recognisable human being, which is, objectively, the most ridiculous sentence I have ever had to write on a professional blog. I blame the robots. It is definitely their fault.

Let’s get one thing straight right out of the gate: the GSD movement is the best thing that happened to AI-assisted development this year. If you’ve been in any builder community recently, you’ve seen frameworks like GSD, Ralph Loop, BMAD, and Superpowers popping up everywhere. And for good reason. They solved the thing that was killing us all.

You know the thing. You sit down with Claude or ChatGPT, start a project, and for the first 30 minutes, you feel like a wizard. Code flows. Architecture emerges. You’re shipping features faster than you can drink your coffee.

Then, three hours later, the AI is “helpfully” refactoring your state management because something in your chat history from two hours ago confused it. Your global store now thinks “water intake” and “bicep curl max” are the same thing. You’re not engineering anymore. You’re babysitting.

GSD and similar frameworks tackled this problem head-on with a brilliant insight: stop dragging context through a single massive conversation. Instead, break work into atomic tasks, give each task a fresh context window, and let a lightweight orchestrator manage the flow. The orchestrator stays lean (around 15% context usage), while each executor gets a pristine 200K token workspace. Task 50 runs with the same quality as Task 1.

It works. It really works. Engineers at Amazon, Google, and Shopify are using it. It turned vibe coding from a gamble into something resembling a repeatable process.

So why am I writing this article?

Because after spending weeks using this pattern, I found a seam. A place where it can go further. And it starts with a question that none of these frameworks explicitly address:

What if the orchestrator and the executor shouldn’t be the same model?

The Blind Spot in Single-Model Orchestration

Here’s the thing about GSD and its siblings. They solved context rot beautifully. Fresh contexts, atomic commits, spec-driven planning. Chef’s kiss.

But there’s a subtlety hidden in the architecture: the orchestrator and the executors are typically the same model. Claude plans the work, Claude does the work, and Claude verifies the work. Different instances, sure. Clean contexts, absolutely. But the same “brain.”

Think about what that means in practice. When the planner creates a task spec, it does so with a particular understanding of code patterns, naming conventions, and architectural trade-offs. When the executor picks up that spec, it brings the exact same biases and blind spots.

It’s like having your CTO and your senior developer be the same person wearing different hats. Sure, they’ll be consistent. But will they catch their own assumptions? Will they challenge their own architectural instincts?

I started noticing this in my own work. The plans were solid. The execution was clean. But I kept finding myself in situations where both the plan and the code shared the same subtle misunderstanding of my project’s constraints. Nobody in the loop was offering a second opinion.

The Architect-Executor Pattern: Splitting the Brain

So I ran an experiment. Instead of letting a single model handle everything, I split the roles among different models. Not just different contexts. Different brains.

Role 1: The Architect (a different model than your executor)

The Architect lives in your codebase. It has a live view of your file tree, your dependencies, and your actual data shapes. But here’s the key rule: the Architect does not write code.

Instead, it thinks at the system level. You throw business problems at it, not coding tasks.

“We need to add a dynamic ‘Add Set’ button to the workout screen, but it needs to tie into the local Zustand store without breaking the existing mocks.”

The Architect reads your files, figures out the dependency chain, and writes a living blueprint. I use a literal implementation_plan.md and a devlog file that grow alongside the project. The Architect is the keeper of the state. It documents what’s been built, what broke, what technical debt exists, and what the next move should be.

Here’s what makes this different from GSD’s planning phase: the Architect adapts continuously. When it looks at your store and realizes that your mock data is an array rather than a dictionary, it adjusts the plan before any code is written. It’s not a one-shot spec. It’s a living conversation with your codebase.

Using a different model family for this role gives you genuine architectural diversity. Different training data, different reasoning patterns, different instincts about what “good code” looks like. That tension is a feature, not a bug.

Role 2: The Executor (your coding powerhouse)

This is where the GSD principle shines hardest, and I kept it: the Executor gets a clean context every single time.

Because the Architect maintains the high-level docs and project state in Markdown files, the Executor doesn’t need to remember yesterday’s conversation. It doesn’t need to remember anything.

The Architect produces a single, perfectly parameterized, atomic prompt. A clean instruction set with all the relevant context baked in. The Executor receives it in a brand new session, sees only the pure context needed for that specific feature, writes the code, commits to Git, and hands back a report.

Zero context degradation. Zero hallucinated dependencies from three hours ago. Zero “helpful” refactors you didn’t ask for.

Role 3: You. The Loop Closer.

You take the Executor’s report, pass it back to the Architect for type-checking and verification, and if it passes, you move on.

You’re no longer doing the prompt-tweak-paste-pray cycle. You’re not micromanaging syntax. You’re not re-reading a 200-message chat history every morning to remember where you left off.

You’ve become the CEO of your own codebase.

What This Gives You Beyond GSD

Let me be specific about where this extends what GSD already does well:

Architectural diversity. GSD uses one model family for everything. My pattern deliberately uses different models for thinking vs. doing. The Architect might catch an assumption that the Executor would blindly follow, and vice versa. It’s the AI equivalent of code review by someone who doesn’t share your mental model.

Model agnosticism. GSD is built around Claude Code (and recently OpenCode and Gemini CLI). My pattern is a methodology, not a framework. You can use whatever combination of models makes sense for your project. Gemini for architecture, Claude for execution. Or swap them. Or use local models for the Architect if you’re working with sensitive code.

Continuous adaptation vs. phase-based planning. GSD’s planning phase produces specs that executors follow. My Architect is a living entity that watches the codebase change and adjusts the plan between every execution cycle. If the Executor’s commit reveals something unexpected, the Architect sees it in the file tree and recalibrates.

Lightweight setup. GSD has commands, agents, workflows, and a .planning/ directory structure. That’s great for larger projects. But sometimes you just need a second brain watching your file tree while you ship features. The Architect-Executor pattern works with nothing more than two chat windows and a shared repo.

Built-in documentation as a side effect. Because the Architect maintains implementation_plan.md and a devlog, you get living project documentation for free. Not as a separate step or ceremony, but as a natural byproduct of how the system works.

When to Use What

Let me be honest about trade-offs, because this isn’t a silver bullet.

Use GSD (or similar frameworks) when: you’re a solo developer who wants a reliable, automated pipeline. You’re starting a greenfield project. You want atomic git commits and automated verification out of the box. You want something that “just works” with a few commands. GSD is genuinely excellent for this.

Use the Architect-Executor pattern when: you’re building something non-trivial where architectural decisions compound. You’ve noticed your AI making the same category of mistakes across planning and execution. You want a second opinion baked into your workflow. You’re comfortable with a more manual, methodology-driven approach. Or you simply want more visibility into what’s happening in your project without having to read chat history.

Combine them. Nothing stops you from using GSD for execution while running a separate Architect model that reviews the .planning/ directory and suggests adjustments. The patterns are complementary, not competing.

The Bigger Picture

Here’s what I think is actually happening in our industry right now. The initial wave of AI-assisted development was “just prompt it and see what happens.” That was exciting, but chaotic. The GSD wave brought structure: specs, clean contexts, atomic execution, verification loops. That was a massive leap forward.

The next wave, and I think we’re just at the beginning of it, is about heterogeneous AI systems. No single model does everything; different models play different roles, challenging each other and compensating for each other’s weaknesses. The same way a real engineering team works.

We don’t hire a team of five identical engineers and put them in separate rooms. We hire people with different backgrounds, different perspectives, and different instincts. Then we put them in the same room and let the creative friction produce something better than any one of them could build alone.

That’s what I’m chasing with the Architect-Executor pattern. Not a replacement for GSD. An evolution of the same core insight: structure makes AI reliable. I’m just adding one more layer of structure: the structure of diverse thinking.

Give it a try. Your codebase (and your mental health) will thank you.

Now, if you’ll excuse me, my Architect just told my Executor to replace the app icon with a picture of the Terminator, and I need to go verify that they haven’t accidentally triggered Skynet.

Keep building, friends. 🚀

Spotify’s co-CEO dropped something during an earnings call a few weeks ago that should have stopped every developer mid-scroll. His most senior engineers, the best people they have, haven’t written a single line of code since December. Not burnout. Not sabbatical. They just don’t need to.

They’re shipping production features to the iOS app from Slack, on their morning commute, before reaching the office.

There is no longer a reasonable debate about whether this changes how we work. The question worth asking is: if typing code is increasingly not the job, what is? And the even harder question underneath that: who are you, if not someone who writes code?

Wait, does any of this actually work, though?

Before the existential crisis fully kicks in, let’s be honest about something.

The same week Spotify is celebrating its AI-powered commute deployment, engineering teams are quietly patching production issues introduced by their AI agent three PRs ago. There are developers who let Claude generate an entire module, merge it because the tests passed, and found out two weeks later that the tests were also generated and were testing the wrong thing entirely.

This is real. Confident, wrong AI output is arguably harder to catch than uncertain, wrong human output, because at least junior developers occasionally write “// not sure about this” in their commits. The AI never writes that. It ships with full conviction and impeccable formatting.

So is the problem the tools, or the people using them?

Honestly, probably both. But I’d lean harder on the second one. The tools have gotten dramatically better. What hasn’t kept up is the practice of using them well. Most developers picked up AI coding the same way they picked up Stack Overflow in 2012: copy, paste, pray, move on. That worked fine when the output was a 12-line function. It works less well when the output is a complete authentication flow.

The irony is that AI rewards exactly the engineering discipline people tend to skip when they’re moving fast. Clear specs. Real tests. Actually, reading the code before merging. When you skip those things while coding manually, you pay a small tax. When you skip them while directing an AI agent, you pay compound interest.

The part I keep watching happen and cringing

Senior developers, experienced people, using AI and merging generated code without really reading it. The PR is green. The review is a formality. And nobody catches the subtle wrong assumption buried in the middle of 200 lines of perfectly formatted TypeScript.

That’s not an AI problem. That’s a thinking problem in an AI costume.

Nate Jones made a sharp observation about this: everyone is so busy debating whether AI replaces or augments engineers that nobody is asking what engineering actually is. And when you ask that question seriously, you realize the stuff AI can’t do is exactly what engineers are supposed to be for in the first place.

From coder to solver. What does that actually mean?

Here’s the reframe that helps me think about this clearly.

A coder’s value is in the output: working code, fast, correct. An AI agent is a better coder than most of us, in most situations, right now. That’s just true, and pretending otherwise is wasted energy.

A solver’s value is in the input: understanding what problem actually needs to be solved, for whom, under what constraints, with what tradeoffs. That’s something completely different. And it’s something AI is genuinely bad at, because it requires context that doesn’t live in a codebase.

Nate’s broader point is that the barrier to building something has shifted. It’s no longer syntax or knowing the right APIs. It’s curiosity about the actual problem, comfort with ambiguity, and the willingness to iterate toward something that makes sense. Those are more like liberal arts skills than computer science skills. Which is uncomfortable to say, but also kind of interesting.

What does that look like in practice for a senior developer?

Domain knowledge over framework knowledge

Knowing how your industry actually works, how your users think, and what constraints your business operates under is increasingly what makes your AI sessions produce something useful rather than something generic. The agent can generate a booking system. Only you know that “booking” in your context means three different things depending on which team is reading the code.

Business fluency is a technical skill

The developer who can sit in a product conversation, understand the actual goal behind a feature request, and push back with “that’s solving the wrong problem” is worth more in 2026 than the developer who can implement whatever spec lands on their plate faster than anyone. One of those developers is a coder. The other is a solver.

Curiosity about the problem, not just the implementation.

This is Nate’s point, and it’s the hardest one to operationalize. It means spending more time before the first prompt asking, “What are we actually trying to do here?” It means being the person who notices the feature request doesn’t match the user’s actual behavior. It means investing in understanding the domain more than the tooling, because the tooling will change again in six months anyway.

Soft skills that are actually hard.

Stakeholder conversations. Knowing when to push back on scope. Reading a room when the technical direction is wrong, and people don’t want to hear it. These have always mattered andhave been consistently undervalued because you couldn’t put them in a commit. In 2026, they’re what differentiates the people AI amplifies from the people AI replaces.

Finding yourself as a senior in 2026

Many senior developers built their confidence on being good at writing code. On knowing the framework deeply. On being the person in the room who understood what was actually happening under the hood.

That identity still matters. But it’s getting separated from the day-to-day of shipping things, which is a genuinely weird feeling that doesn’t have a clean resolution. Nobody really talks about it.

What seems to work is shifting the identity from “person who writes good code” to “person who produces correct outcomes.” The tool changed. The standard didn’t. You’re still the one responsible for what goes to production, still the one who knows whether a feature is solving the right problem, still the one who catches the architectural decision that will make everyone miserable in eighteen months.

If anything, that responsibility got heavier, not lighter. There’s more code moving faster, with less friction to slow you down when the direction is wrong.

The developers pulling ahead right now aren’t the purists refusing to touch AI. They’re not the ones merging without reading, either. They’re the ones who figured out that the interface between their thinking and the machine’s output is where the actual work lives, and invested accordingly.

Not in the tools. In the thinking.

Which, when you put it that way, has always been the job.

But then reality slapped me in the face like a failed production deployment at 4 PM on Friday.

Between the conference hype and reading about these orchestrator workflows, I started reflecting on what I’m actually seeing in day-to-day development. And honestly? We need to have an uncomfortable conversation about what I’m calling “The Magic Wand Syndrome”: developers who think their AI coding assistant is literally magic that... makes correct code appear.​

Spoiler alert: It’s not. You’re not a wizard. And that spell you just cast? Yeah, it summoned a demon that’s gonna haunt your codebase for the next six months.

The Vibe Coding Epidemic

Let me paint you a picture. It’s Tuesday morning. Someone pushes a PR. Beautiful, clean-looking code. Merges through. Everyone’s happy.

Wednesday afternoon: Production is on fire. The person who wrote it? “Uh... I mean... the AI generated it, and the tests passed, so...”

This is what industry folks are calling “vibe coding“ and honestly? The name is perfect. It’s like coding by vibes only: no architecture, no understanding, “AI give me feature plz” and then YOLO’ing it into main.​

Here’s the thing that makes me want to scream into a pillow: I’m seeing PRs from people who literally cannot explain what their own code does. Not because it’s complex. Because they never actually read it. The AI wrote it; the tests went green (somehow). Ship it! 🚀​

And look, I get it. We’ve all been there late at night trying to finish a ticket, prompting AI with increasingly desperate variations of the same question until something works. But that’s not development; that’s just guessing with extra steps and a $20/month subscription.

Recent observations show a troubling pattern: developers input entire problems into AI tools, receive partially functional code, then struggle to debug it or explain their design decisions. They try to fix issues with vague commands like “refactor the code” without providing meaningful context.​

The “House of Cards” We’re All Building

Fun fact that’ll keep you up at night: GitClear analyzed 211 million lines of code and found that AI-driven development is creating technical debt faster than anyone’s ever seen. Veterans with 35+ years of experience are basically going “what the actual hell” at how quickly codebases are turning into unmaintainable messes.​

The cycle goes like this:

1. AI generates code (fast! shiny! works... kinda!)

2. You accept it without fully understanding it

3. Subtle bugs emerge (weird edge cases, performance issues, that thing that only breaks in Safari)

4. Use AI to patch the bugs

5. Patches create new complexity

6. More patches, more complexity, more bandaids

7. Wake up six months later with a Frankenstein codebase held together by AI-generated duct tape

And here’s the kicker: 67% of developers now spend more time debugging AI-generated code than they save from initial generation. Another 68% spend more time resolving security vulnerabilities. Research shows 40% of AI-generated code contains vulnerabilities, with only 55% being secure enough for production.​

So what exactly are we optimizing for here? Carpal tunnel prevention? Because it’s certainly not “sustainable software development.”

The Experience Gap Nobody Talks About

Here’s an uncomfortable truth from recent research: AI coding tools help experienced developers WAY more than junior ones.​

Why? Because seniors can look at AI output and immediately spot when it’s:

• Hallucinating logic that seems right but isn’t

• Producing functionally correct but architecturally terrible code

• Copy-pasting patterns that don’t fit the actual use case

• Creating security vulnerabilities wrapped in helpful comments

Meanwhile, juniors (and honestly, some not-so-juniors) are playing “AI trial-and-error roulette”: keep prompting with slight variations, never actually tracing the root cause, vibe until something compiles.

The difference? Foundational knowledge. Seniors aren’t magic either; they have the experience to spot when AI is confidently wrong.

The Skills Crisis We’re Creating

Here’s what keeps me up at night: If AI does 90% of our coding work, how do the next generation of developers learn the fundamentals needed to actually use AI effectively?​

It’s a chicken-and-egg problem. You need foundational knowledge to validate AI output. But if AI is doing all the work, when do you build that foundation?

Junior developers historically learned by doing the grunt work: building simple components, fixing small bugs, writing utility functions. That’s where you develop pattern recognition and learn what “good code” feels like.

But AI just... does all that now. So we’re creating a generation of developers who can prompt AI but can’t debug when the AI gets it wrong, which it does. Constantly.

The traditional learning path is disappearing. Junior roles that once served as training grounds are being automated away. New CS graduates are struggling because they can generate code with AI but lack the judgment to know if it’s actually good. They’re caught in a paradox: they need experience to use AI effectively, but AI is eliminating the entry-level work that builds that experience.​

Look, I’m Not Anti-AI

Before you think I’m some Luddite typing this on a mechanical keyboard by candlelight: I use AI tools literally every single day. They’re phenomenal. Cursor, Claude, Windsurf; they’ve all saved me countless hours in my daily development tasks.

But here’s my approach, and why I’m not currently experiencing the “oh god, why is everything broken” phenomenon:

1. Understand Before You Accept

When AI generates code, I actually read it. Revolutionary concept, I know. I understand what it’s doing, why it’s doing it that way, and whether there’s a better approach.

If I can’t explain it to a rubber duck, I don’t ship it. Period.

2. Small, Controlled Changes

I’m not spinning up three AI agents to rebuild my entire feature set while I make coffee. I use AI for one thing at a time. Generate a component. Review it. Test it. Understand it. Then move on.​

This isn’t slower; it’s sustainable. Because I’m not spending next week debugging mysterious issues in code I don’t understand.

3. Architecture First, Magic Second

Before I even think about prompting an AI, I know:

• What problem am I solving

• How it fits into the existing system

• What the data flow looks like

• What could potentially break

The AI helps with implementation, not design. If you’re using AI to design your architecture, we need to have a different conversation (probably involving your tech lead).

4. Tests Are Not Optional

“But the AI wrote tests!” Cool. Did you read them? Do they actually test meaningful scenarios or just happy-path nonsense that gives you a false sense of security?

I’ve seen AI-generated test suites that would make a QA engineer weep. 100% code coverage, 0% actual validation.

How to Actually Become an AI Supervisor (Not Just a Prompt Monkey)

Okay, so you’re convinced that blindly accepting AI output is a bad idea. Great! But how do you actually transition from “vibe coder” to “effective AI supervisor”? Here’s what I’ve learned:

For Everyone Still Learning

Treat AI Like a Very Confident Junior Developer
Because that’s precisely what it is. It confidently generates code that looks right but might be fundamentally flawed. Would you merge a junior’s PR without reviewing it? No? Then don’t do it with AI.

Use AI as a Learning Tool, Not a Replacement
Instead of asking “write me a function that does X”, try “explain how I would implement X, then show me an example”. This forces you to understand the approach before seeing the implementation. GitHub’s research shows that configuring AI tools to teach rather than do dramatically improves skill development.​

Build Your Pattern Recognition
Work through the AI’s suggestions line by line. Ask yourself:

• Why did it choose this approach?

• What are the tradeoffs?

• What edge cases might it have missed?

• How would I have done this differently?

This is how you build the intuition that separates effective AI users from prompt monkeys.

Master One Thing Deeply Before Scaling
Don’t jump straight to orchestrating multiple AI agents. Master working with one agent in conductor mode first. Understand how to give it good context, how to validate its output, and how to iterate when it gets things wrong. Then consider more advanced workflows.​

For Experienced Devs Feeling the Pressure

Don’t Get Complacent
Just because you can validate AI output today doesn’t mean you’ll be able to tomorrow if you stop practicing. Keep writing code manually for complex features. Your skills are like muscles; they atrophy without use.

Create Validation Checklists
Build yourself a mental (or actual) checklist for reviewing AI-generated code:

• Does it follow our architecture patterns?

• Are there security implications?

• Is it maintainable?

• Does it handle errors properly?

• Will the next person understand this?

Share Your Process
If you’re effectively using AI tools, teach others how you’re doing it. Not just “I use Cursor,” but “Here’s how I scope tasks, validate output, and iterate on results.” The team that learns together doesn’t create technical debt together.

For Teams and Tech Leads

Rethink Code Review for the AI Era
Code review becomes exponentially more critical when AI generates the code. The bottleneck isn’t AI speed; it’s our ability to read and validate what it produces quickly.

Consider:

• Requiring explanations of AI-generated code in PR descriptions

• Asking “Can you walk me through this?” in reviews

• Flagging PRs that seem to be pure AI output for extra scrutiny

Create Safe Spaces for Learning
Junior developers need opportunities to build foundational skills even as AI automates away traditional learning tasks. Consider:

• Dedicated “no AI” projects or features for skill building

• Pairing juniors with seniors to learn validation techniques

• Code review sessions focused on understanding not just shipping

Establish AI Usage Guidelines
Not “don’t use AI” but “here’s how we use AI responsibly”:

• Architecture and design decisions remain human

• All AI output must be reviewed and understood

• Security-critical code requires extra validation

• Test quality is non-negotiable

The Long Game: Controlled Orchestration

I’m not against the orchestrator model Addy describes. Multi-agent workflows have genuine potential. But we need guardrails:​

Start as a Conductor: Master working with a single AI agent interactively before trying to manage multiple autonomous agents. Learn to give good prompts, validate output, and iterate effectively.

Architecture Always First: Before delegating to AI agents, understand your system architecture deeply. Design the interfaces, define the boundaries, and map the data flows. The AI can help build the house, but you need to design it.

Incremental Autonomy: Give AI agents increasing autonomy as you become better at validating their output. Don’t jump straight to fire-and-forget mode. Earn the right to trust your AI by proving you can catch its mistakes.

Maintain Your Skills: Keep writing code manually for complex features. Your ability to evaluate AI output depends on maintaining your fundamental skills. The best orchestrators are still excellent musicians.

The Uncomfortable Reality

Here’s the thing nobody wants to say out loud: using AI effectively is more complex than writing code manually.

Wait, what?

Yeah. Writing code yourself is straightforward: you think, you type, you debug. Using AI effectively requires:

• Understanding the problem deeply enough to prompt correctly

• Validating the solution for correctness and quality

• Integrating it into your existing architecture

• Debugging when things go wrong (which they will)

• Explaining it to others on your team

The AI doesn’t make you faster by reducing the cognitive load. It makes you faster by amplifying your existing skills. If those skills are weak, you’re just amplifying weakness.

This is why seniors see massive productivity gains and juniors... don’t. It’s not about access to better tools. It’s about having the foundation to use those tools effectively.

So Where Do We Go From Here?

The future Addy describes is coming whether we like it or not. AI coding assistants are getting more autonomous, more capable, more integrated into our workflows. The orchestrator model will become reality for many development tasks.​

But we can choose how we get there.

We can rush headlong into it, vibing our way to unmaintainable codebases and a generation of developers who can’t debug their own systems. Or we can be intentional: build skills, maintain standards, and treat AI as a powerful tool that requires expertise to wield effectively.

I know which path I’m choosing. And honestly? After the AI Poland conference and reading about these new orchestrator tools, I’m more convinced than ever that the developers who win aren’t the ones who use AI the most; they’re the ones who use it the best.

So slow down. Understand your code. Review those PRs. Question the AI’s decisions. Maintain your fundamentals.

Because when that production system breaks (and it will), the AI agent won’t be the one fixing it. You will. And you’d better understand how it works.

Further Reading:

• Addy Osmani’s article on Conductors to Orchestrators​

• Why AI-Generated Code Is Creating a Technical Debt Nightmareokoone​

• What’s The Problem With Vibe Coding?​

What’s your experience with AI coding tools? Seeing quality issues in your codebase? Drop your thoughts in the comments; this conversation is too meaningful to leave unfinished.

P.S. If you recognized yourself in this post, don’t worry, we’ve all been there. The first step is admitting you have a vibe coding problem. The second step is actually reading your PRs before you merge them. You got this.

See PFC in action with a real admin dashboard. Three features (user management, analytics, notifications) are composed on one page. Complete walkthrough of folder structure, feature implementation, facades, containers, and final page composition. This is what clean Angular architecture looks like in production.

Welcome to the final post in the Page-Feature Composition series. We’ve covered the philosophy, page orchestration, feature architecture, and migration strategies.

Now let’s put it all together with a complete, real-world example.

We’re building an admin dashboard that displays:

• Recent users with quick actions

• Analytics overview with charts

• Real-time notifications feed

Three features, one page, zero spaghetti code.

Series Context: This is the final part of the Page-Feature Composition series. If you haven’t read parts 1-4, start there for the foundational concepts. This post shows everything working together.

The Dashboard Requirements

Our admin dashboard needs to:

Show recent users

• Display the last 10 active users

• Quick view/edit/delete actions

• Click to navigate to full user management

Display analytics

• Total users, active sessions, revenue

• Simple chart showing trends

• Refresh on demand

Show notifications

• Real-time notification feed

• Mark as read functionality

• Badge count on unread items

Page responsibilities

• Arrange features in a grid layout

• Handle navigation when users click items

• That’s it!

Let’s build it.

Project Structure

Here’s our complete folder organization:

src/app/
├── features/
│   ├── user-management/
│   │   ├── components/
│   │   │   └── user-card/
│   │   ├── containers/
│   │   │   └── user-management-container/
│   │   ├── store/
│   │   │   └── facade.ts
│   │   ├── services/
│   │   │   └── user-api.service.ts
│   │   ├── models/
│   │   │   └── user.interface.ts
│   │   ├── user-management.facade.ts
│   │   ├── user-management.module.ts
│   │   └── index.ts
│   │
│   ├── analytics/
│   │   ├── components/
│   │   │   └── stats-card/
│   │   ├── containers/
│   │   │   └── analytics-container/
│   │   ├── store/
│   │   ├── services/
│   │   ├── analytics.facade.ts
│   │   ├── analytics.module.ts
│   │   └── index.ts
│   │
│   └── notifications/
│       ├── components/
│       │   └── notification-item/
│       ├── containers/
│       │   └── notifications-container/
│       ├── store/
│       ├── services/
│       ├── notifications.facade.ts
│       ├── notifications.module.ts
│       └── index.ts
│
├── pages/
│   └── admin-dashboard/
│       ├── admin-dashboard.page.ts
│       ├── admin-dashboard.html
│       ├── admin-dashboard.scss
│       └── admin-dashboard.module.ts
│
└── shared/
    └── components/

Three focused features. One orchestrating page. Clean separation.

Feature 1: User Management

What It Does

Handles everything related to displaying and managing users in “compact” mode for the dashboard.

Models

If it’s being used only by the model, keep inside the feature; otherwise, move to shared (as in here)

// shared/models/user.interface.ts
export interface User {
  id: string;
  name: string;
  email: string;
  avatar: string;
  lastActive: Date;
  status: ‘active’ | ‘inactive’;
}

Store Facade (Internal)

// features/user-management/store/facade.ts
@Injectable({ providedIn: ‘root’ })
export class UserStoreFacade {
  readonly users$ = this.store.select(selectUsers);
  readonly isLoading$ = this.store.select(selectIsLoading);

  constructor(private store: Store) {}

  loadRecentUsers(): void {
    this.store.dispatch(loadRecentUsers());
  }

  deleteUser(userId: string): void {
    this.store.dispatch(deleteUser({ userId }));
  }
}

Container

// features/user-management/containers/user-management-container/user-management.container.ts
@Component({
  selector: ‘app-user-management-container’,
  templateUrl: ‘./user-management.html’
})
export class UserManagementContainer implements OnInit {
  @Input() mode: ‘full’ | ‘compact’ = ‘full’;
  @Input() maxItems?: number;
  @Output() userSelected = new EventEmitter<string>();

  users$ = this.storeFacade.users$;
  isLoading$ = this.storeFacade.isLoading$;

  constructor(private storeFacade: UserStoreFacade) {}

  ngOnInit(): void {
    this.storeFacade.loadRecentUsers();
  }

  get displayUsers$() {
    return this.users$.pipe(
      map(users => this.maxItems ? users.slice(0, this.maxItems) : users)
    );
  }

  onUserClick(userId: string): void {
    this.userSelected.emit(userId);
  }

  onUserDelete(userId: string): void {
    if (confirm(’Delete this user?’)) {
      this.storeFacade.deleteUser(userId);
    }
  }
}

Presentational Component

// features/user-management/components/user-card/user-card.component.ts
@Component({
  selector: ‘app-user-card’,
  templateUrl: ‘./user-card.html’,
  styleUrls: [’./user-card.scss’]
})
export class UserCardComponent {
  @Input() user: User;
  @Input() compact = false;
  @Output() click = new EventEmitter<string>();
  @Output() delete = new EventEmitter<string>();

  onClick(): void {
    this.click.emit(this.user.id);
  }

  onDelete(event: Event): void {
    event.stopPropagation();
    this.delete.emit(this.user.id);
  }
}

Feature Facade (Public API)

// features/user-management/user-management.facade.ts
@Injectable()
export class UserManagementFacade {
  readonly isLoading$ = this.storeFacade.isLoading$;

  constructor(private storeFacade: UserStoreFacade) {}

  refreshUsers(): void {
    this.storeFacade.loadRecentUsers();
  }
}

Public Exports

// features/user-management/index.ts
export * from ‘./user-management.module’;
export * from ‘./user-management.facade’;

That’s the complete user-management feature. Self-contained, testable, reusable.

Feature 2: Analytics (Simplified)

What It Does

Displays key metrics and a simple chart. Handles data loading and formatting.

Container

// features/analytics/containers/analytics-container/analytics.container.ts
@Component({
  selector: ‘app-analytics-container’,
  templateUrl: ‘./analytics.html’
})
export class AnalyticsContainer implements OnInit {
  @Input() mode: ‘full’ | ‘summary’ = ‘full’;

  stats$ = this.storeFacade.stats$;
  isLoading$ = this.storeFacade.isLoading$;

  constructor(private storeFacade: AnalyticsStoreFacade) {}

  ngOnInit(): void {
    this.storeFacade.loadStats();
  }

  refresh(): void {
    this.storeFacade.loadStats();
  }
}

Stats Card Component

// features/analytics/components/stats-card/stats-card.component.ts
@Component({
  selector: ‘app-stats-card’,
  templateUrl: ‘./stats-card.html’,
  styleUrls: [’./stats-card.scss’]
})
export class StatsCardComponent {
  @Input() label: string;
  @Input() value: number;
  @Input() icon: string;
  @Input() trend?: ‘up’ | ‘down’;
}

The analytics feature is complete. Simple, focused, reusable.

Feature 3: Notifications (Simplified)

What It Does

Displays real-time notifications, allows marking as read, and shows unread count.

Container

// features/notifications/containers/notifications-container/notifications.container.ts
@Component({
  selector: ‘app-notifications-container’,
  templateUrl: ‘./notifications.html’
})
export class NotificationsContainer implements OnInit {
  @Input() maxItems = 10;

  notifications$ = this.storeFacade.notifications$;
  unreadCount$ = this.storeFacade.unreadCount$;

  constructor(private storeFacade: NotificationsStoreFacade) {}

  ngOnInit(): void {
    this.storeFacade.loadNotifications();
  }

  get displayNotifications$() {
    return this.notifications$.pipe(
      map(items => items.slice(0, this.maxItems))
    );
  }

  onMarkAsRead(id: string): void {
    this.storeFacade.markAsRead(id);
  }

  onMarkAllRead(): void {
    this.storeFacade.markAllAsRead();
  }
}

Notification Item Component

// features/notifications/components/notification-item/notification-item.component.ts
@Component({
  selector: ‘app-notification-item’,
  templateUrl: ‘./notification-item.html’,
  styleUrls: [’./notification-item.scss’]
})
export class NotificationItemComponent {
  @Input() notification: Notification;
  @Output() markRead = new EventEmitter<string>();

  onMarkRead(): void {
    this.markRead.emit(this.notification.id);
  }
}

The notifications feature is complete. Handles its own complexity.

The Page: Bringing It All Together

Now the magic happens. The page composes features.

Page Component

// pages/admin-dashboard/admin-dashboard.page.ts
@Component({
  templateUrl: ‘./admin-dashboard.html’,
  styleUrls: [’./admin-dashboard.scss’]
})
export class AdminDashboardPage {
  constructor(private router: Router) {}

  onUserSelected(userId: string): void {
    this.router.navigate([’/users’, userId]);
  }
}

That’s it. 8 lines. No business logic. Just navigation.

Page Template

<!-- pages/admin-dashboard/admin-dashboard.html -->
<div class=”dashboard-layout”>
  <header class=”dashboard-header”>
    <h1>Admin Dashboard</h1>
    <p>Welcome back! Here’s your overview.</p>
  </header>

  <div class=”dashboard-grid”>
    <!-- Analytics Feature -->
    <section class=”analytics-section”>
      <app-analytics-container mode=”summary”></app-analytics-container>
    </section>

    <!-- User Management Feature -->
    <section class=”users-section”>
      <div class=”section-header”>
        <h2>Recent Users</h2>
        <a routerLink=”/users”>View all</a>
      </div>
      <app-user-management-container
        mode=”compact”
        [maxItems]=”10”
        (userSelected)=”onUserSelected($event)”>
      </app-user-management-container>
    </section>

    <!-- Notifications Feature -->
    <section class=”notifications-section”>
      <div class=”section-header”>
        <h2>Notifications</h2>
        <span class=”unread-badge”>3</span>
      </div>
      <app-notifications-container
        [maxItems]=”5”>
      </app-notifications-container>
    </section>
  </div>
</div>

Pure composition. Three features, one layout, zero logic.

Page Styling

// pages/admin-dashboard/admin-dashboard.scss
.dashboard-layout {
  padding: 2rem;
}

.dashboard-grid {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 2rem;
  
  @media (max-width: 1024px) {
    grid-template-columns: 1fr;
  }
}

.analytics-section {
  grid-column: 1 / -1; // Full width
}

.section-header {
  display: flex;
  justify-content: space-between;
  align-items: center;
  margin-bottom: 1rem;
}

Layout is a page concern. Features don’t care where they’re placed.

Page Module

// pages/admin-dashboard/admin-dashboard.module.ts
@NgModule({
  declarations: [AdminDashboardPage],
  imports: [
    CommonModule,
    RouterModule.forChild([
      { path: ‘’, component: AdminDashboardPage }
    ]),
    // Import feature modules
    UserManagementModule,
    AnalyticsModule,
    NotificationsModule
  ]
})
export class AdminDashboardModule { }

Lazy-loaded page imports the features it needs.

What We’ve Achieved

Let’s look at what this architecture gives us:

Reusability

User Management Feature can be used:
- Admin dashboard (compact mode, 10 users)
- Full user management page (full mode, all users)
- User selection dialog (selection mode)
- Profile sidebar (compact mode, 1 user)

Same feature, different contexts, zero modifications.

Analytics Feature works on:
- Admin dashboard (summary mode)
- Analytics page (full mode with charts)
- Mobile app dashboard (summary mode)

Notifications Feature appears:
- Dashboard (compact, 5 items)
- Header dropdown (compact, 3 items)
- Notifications page (full, all items)

Testability

describe(’UserManagementContainer’, () => {
  it(’should load users on init’, () => {
    const facade = jasmine.createSpyObj(’UserStoreFacade’, [’loadRecentUsers’]);
    const container = new UserManagementContainer(facade);
    
    container.ngOnInit();
    
    expect(facade.loadRecentUsers).toHaveBeenCalled();
  });
});

Test page composition:

describe(’AdminDashboardPage’, () => {
  it(’should navigate when user selected’, () => {
    const router = jasmine.createSpyObj(’Router’, [’navigate’]);
    const page = new AdminDashboardPage(router);
    
    page.onUserSelected(’user-123’);
    
    expect(router.navigate).toHaveBeenCalledWith([’/users’, ‘user-123’]);
  });
});

Clean, simple tests.

Team Workflow

Parallel development:
- Developer A: User management feature
- Developer B: Analytics feature
- Developer C: Notifications feature
- Developer D: Dashboard page composition

No conflicts. No waiting. Pure parallelization.

Maintainability

Six months later, you need to add a filter to user management. Where do you look? The user-management feature. Not scattered across five different pages.

Need to update the analytics chart? Analytics feature. One place. Clear boundary.

Bug in notifications? Notifications feature. Isolated problem, isolated fix.

Alternative Page Layouts

Because features are composable, you can create different layouts easily.

Mobile Dashboard (Vertical Stack)

<!-- pages/mobile-dashboard/mobile-dashboard.html -->
<div class=”mobile-layout”>
  <app-analytics-container mode=”summary”></app-analytics-container>
  <app-notifications-container [maxItems]=”3”></app-notifications-container>
  <app-user-management-container mode=”compact” [maxItems]=”5”></app-user-management-container>
</div>

Same features, different order, mobile-specific layout.

Executive Dashboard (Different Focus)

<!-- pages/executive-dashboard/executive-dashboard.html -->
<div class=”executive-layout”>
  <app-analytics-container mode=”full”></app-analytics-container>
  <!-- No users, no notifications - just analytics -->
</div>

Pick and choose features as needed.

Custom Client Dashboard

<!-- pages/client-dashboard/client-dashboard.html -->
<div class=”client-layout”>
  <!-- Different features for client view -->
  <app-project-status-container></app-project-status-container>
  <app-billing-summary-container></app-billing-summary-container>
  <app-support-tickets-container></app-support-tickets-container>
</div>

Create new dashboards by combining and customizing features.

Key Patterns Demonstrated

Container/Component Split

Containers handle logic and state. Components are pure presenters. This makes components highly reusable and easy to test.

Facade Pattern

Each feature exposes a simple facade. Pages use it for programmatic actions. Internal complexity stays hidden.

Input/Output Communication

Features expose inputs for configuration and outputs for events. Pages coordinate but don’t implement.

Mode-Based Behavior

Features support different modes via inputs. Same feature, different contexts, no code duplication.

Lazy Loading

Pages are lazy-loaded routes. Features are imported by pages that need them. Optimal bundle sizes.

Common Questions

”Isn’t this over-engineered for a simple dashboard?”

For a toy project, yes. For a production app that will grow, no. The structure supports growth without complexity explosion.

”What if features need to share data?”

Let the page coordinate. Feature A emits event, page passes data to Feature B via input. Keep features independent.

”Can features use each other’s components?”

No. Features are independent. If you need shared components, put them in `shared/`. If two features overlap significantly, maybe they’re one feature.

”How do I handle authentication?”

Core concern, not a feature. Put it in `core/auth/`. Features can inject auth services when needed.

”What about shared utilities?”

``shared/` folder. Pipes, utility functions, truly generic components. Not business-domain-specific.

Summary

This is what PFC looks like in production. Three focused features. One orchestrating page. Clean separation. Easy testing. True reusability.

What we built:
✅ User management feature (complete CRUD capability)
✅ Analytics feature (stats and charts)
✅ Notifications feature (real-time feed)
✅ Admin dashboard page (pure composition)
✅ Alternative layouts (mobile, executive, client)

What we achieved:
✅ Features work in multiple contexts without modification
✅ Page is <10 lines of business logic
✅ Tests are simple and isolated
✅ Team can work in parallel
✅ Maintenance is predictable

What you should do next:
Build one feature this way. See how it feels. Experience the benefits firsthand. Then build another. And another. Before you know it, you’ll have a scalable, maintainable Angular application.

Series Wrap-Up

We’ve covered a lot across five posts:

PFC #1: The philosophy and high-level structure
PFC #2: Pages as orchestrators
PFC #3: Building bulletproof features
PFC #4: Migration strategies
PFC #5: Complete real-world example

You now have everything you need to adopt PFC in your projects.

Start small. Build one feature. Show your team. Let the benefits speak for themselves.

Happy composing! 🎯

This concludes the Page-Feature Composition series. Follow better-frontend.dev for more practical Angular architecture insights.

The Series:
- PFC #1 - The Philosophy
- PFC #2 - Pages as Orchestrators
- PFC #3 - Building Features
- PFC #4 - Migration Strategies
- PFC #5 - Real-World Examples ← You are here

You don’t need to rewrite your entire app to adopt PFC. Start with one new feature or refactor one messy page. Use the strangler pattern: build new features with PFC, gradually extract from monoliths, and let old and new coexist during migration. Most teams see value within 2-3 sprints without disrupting ongoing work.

In PFC #1, PFC #2, and PFC #3, we covered the theory and architecture. Now comes the hard part: actually doing it.

You’ve got an existing codebase. Maybe 50 routes. Maybe 200 components. Maybe years of “temporary” solutions. The question isn’t “Should we adopt PFC?” It’s “How do we adopt PFC without stopping all feature development for six months?”

Good news: You don’t rewrite everything. You migrate gradually.

Series Context: This is Part 4 of the Page-Feature Composition series. This post assumes you understand PFC principles from parts 1-3. We’re focused purely on practical migration.

The Core Philosophy: Divide and Conquer

PFC is built on the ancient principle of “divide and conquer.”

The idea is simple: break complex problems into smaller, manageable, reusable pieces. Instead of one 2000-line component trying to do everything, you have focused features that each do one thing well.

The beauty? Once you divide correctly:

• Features become truly reusable across different pages

• Teams can work in parallel without conflicts

• Testing becomes straightforward

• Bugs have clear boundaries

The trick is knowing how to divide. What makes a good feature boundary?

How Big Should a Feature Be?

This is the million-dollar question. The answer: start small and logically encapsulate one part of your app.

The Golden Rule

Too small is always better than too big.

Seriously. A feature that’s too small can easily be merged with another later. A feature that’s too large becomes a mini-monolith, defeating the whole purpose of PFC.

When in doubt, go smaller. You can always combine features later if you realize they’re too granular. You can’t easily split a massive feature that’s already coupled to everything.

What Makes a Good Feature?

Think of features as logical business capabilities that can stand alone.

Good feature boundaries:

User Management - Handles all aspects of user management, including listing, creating, editing, deleting, and searching. Includes all user-related forms and displays. Can answer “Show me users” in any context.

Product Catalog - Handles products: browse, filter, create, edit, and details. Includes product forms, cards, grids, and filters. Can answer “Show me products” in any context.

Order Processing - Handles orders, including creation, viewing, updating status, and tracking. Includes order forms, order lists, and status displays. Can answer “Show me orders” in any context.

Each one is complete and independent. You could develop the user-management feature without the products existing. You could test it in isolation. You could use it on five different pages.

Start Small, Grow Organically

Don’t try to build the perfect feature structure on day one. Start with the smallest logical unit.

Example: Building a shopping app

Don’t start with one giant “e-commerce” feature handling products, cart, checkout, orders, and payments.

Start with small, focused features:

• Product catalog feature (just products)

• Then add the shopping cart feature (just the cart)

• Then add checkout feature (just checkout flow)

• Then add the order history feature (just past orders)

Four focused features consistently outperform one massive feature.

The “Elevator Pitch” Test

Can you describe what the feature does in one sentence without using “and”?

✅ Good: “User management handles all user CRUD operations”

❌ Too big: “E-commerce handles products, shopping cart, checkout, orders, and payments”

If you need “and”, you probably have multiple features hiding in there.

The “Can It Live Alone?” Test

Before creating a feature, ask:

1. Can I develop this without other features existing? Yes → Good feature

2. Can I test this in complete isolation? Yes → Good feature

3. Can I use this on multiple different pages? Yes → Good feature

4. Does it handle ONE clear business domain? Yes → Good feature

If you pass all four tests, you’ve found a reasonable feature boundary.

Practical Sizing Advice

Start here:

• 3-7 components per feature

• 1-2 containers per feature

• Focused on one business domain

• Takes 1-2 sprints to build the initial version

If you’re not sure, err on the side of caution and choose the smaller option. You can always combine later.

Remember: Too small beats too big, every time.

The Mindset Shift

Stop thinking: “We need to refactor the whole app.”

Start thinking: “What’s the smallest valuable change we can make?”

Migration isn’t a project. It’s a practice. You don’t set aside three months to “do PFC.” You adopt it incrementally, one feature at a time, while continuing to ship new features.

The Strangler Pattern

Named after strangler fig trees that gradually replace their host trees.

The idea:

1. Build new features using PFC

2. Extract pieces from old monoliths when you touch them

3. Let old and new coexist peacefully

4. Over time, PFC becomes the majority

No significant bang rewrite. No project plan. Just better decisions going forward.

Migration Strategies

Select the option that best suits your situation.

Strategy 1: Start with New Features

Best for: Teams actively building new features

When you need to build something new, build it the PFC way. Create the features and pages folders alongside your existing code. New features go into the new structure. Old code stays where it is.

Timeline: Immediate. No refactoring needed.

Strategy 2: Extract One Messy Page

Best for: Teams with one particularly problematic page

Pick your messiest page component and identify the distinct business concerns it handles. Create a small, focused feature for each concern. Move the logic out of the page into features. Update the page to simply compose those features.

Timeline: 1-2 sprints for one page.

Strategy 3: Refactor When You Touch It

Best for: Teams with stable codebases, infrequent changes

The “Boy Scout Rule”: Leave code better than you found it. When fixing a bug or adding a feature, extract just the part you’re changing into a small feature. Leave the rest as-is. Over time, the page gets cleaner.

Timeline: No dedicated time. Happens during normal work.

Deconstructing the Kitchen Sink

Let’s walk through extracting features from a monolithic component, one at a time.

The Problem: Kitchen Sink Component

Imagine your admin page: 500+ lines handling users, products, and orders. Everything mixed together. Services injected for all three domains. The state is scattered everywhere. Methods for every possible action.

It’s unmaintainable. Let’s fix it gradually.

Step 1: Extract First Feature (Users)

Sprint 1: Focus only on users.

Create the user-management feature. Move all user-related logic from the page into the feature’s container. The container handles loading, users, searching, selecting, and deleting. All the user complexity now resides in the feature.

Update your page: replace all the inline user code with the user-management container component. Your page places the container in the template.

Result: Your page component shrinks from 500 lines to ~350 lines. All user services and states have been removed from the page. Progress!

Step 2: Extract Second Feature (Products)

Sprint 2: Now tackle products.

Create the product-catalog feature. Move all product-related logic into this feature’s container. Product loading, filtering, and editing - all moves to the feature.

Update your page again: replace the inline product code with the product-catalog container.

Result: Page is now ~200 lines. Two features extracted. Getting cleaner!

Step 3: Extract Third Feature (Orders)

Sprint 3: Finally, orders.

Create the order-processing feature. Move all order logic into the feature’s container.

Update the page one last time: replace the inline order code with the order-processing container.

Result: Page is now ~50 lines. Almost nothing is left but orchestration.

Step 4: Migrate to Clean Page Component

Sprint 4: Final cleanup.

Move the remaining orchestration logic to a new, clean page component in your pages/ folder. The page just composes the three feature containers and handles navigation.

When a user is selected, the page navigates to the user detail route. When a product is clicked, route to product details. That’s all the page does.

Final result: Went from 500+ lines to ~30 lines. Three focused features. Clean orchestration. Pure composition.

Passing Context to Features

Pages extract context from routes (like IDs) and pass them as inputs to features. The feature receives the ID, loads the data, and displays it. Clean separation.

Example: The user detail page retrieves the user ID from the route, passes it to the user-management container in “detail” mode with the ID. The feature handles the rest.

Handling Legacy Dependencies

Bridging Old Services

Your new features may need to utilize existing centralized services temporarily. That’s okay. Wrap the old service in your feature’s new service. Delegate to it temporarily. Replace the implementation later when you’re ready. No rush.

Shared State

Old and new code might need to share data during migration. Let them temporarily share the feature’s store. Document it as a TODO. Fix it when you can. Keep moving forward.

Team Workflow

Clear Ownership: Small features mean one developer or pair owns each feature. Parallel development becomes natural.

Code Review Focus: Verify that new features are concise, focused, and adhere to the PFC structure. For legacy code, encourage extraction but don’t demand perfection. Praise progress.

Documentation: Create a simple one-page guide showing the feature template and basic rules. Keep it minimal.

Common Challenges

“How do we decide feature boundaries?”
Start small. Use the “Elevator Pitch” test. One sentence, no “and”. If it passes and can live alone, it’s good.

“What if we make features too small?”
Better than too big! You can combine later. You can’t easily split a massive feature.

“Our codebase is too big.”
Doesn’t matter. Start with one small feature. Prove value. Expand organically.

“Team doesn’t know PFC”
Share the posts. Extract one feature together. Learn by doing. Start small.

“What about existing tests?”
Keep them. They still test old code. Write new tests for new features. Delete old tests when old code is removed. Gradual transition.

When NOT to Migrate

Skip if: App sunsetting soon, tiny, overwhelmed team, already well-organized, pure maintenance mode.

Delay if: Major deadline approaching, team crisis

Timing matters.

Summary

Migration is a divide-and-conquer approach through small, focused features extracted one at a time.

Key takeaways:

✅ Start small - too small beats too big
✅ Extract one feature per sprint from monoliths
✅ Let old and new coexist during migration
✅ Move to clean page component when all features extracted
✅ Pass context (IDs, params) as inputs to features
✅ Use “Elevator Pitch” and “Can It Live Alone?” tests
✅ First feature is hardest; gets easier

Start tomorrow. Extract one small feature from your messiest page. Show value. Repeat.

What’s Next

PFC #5 - Real-World Examples
Complete implementation walkthrough. Dashboard with multiple features working together.

Your Migration Plan

1. Which strategy? (New features / Extract page / Refactor on touch)

2. What’s your messiest page? (Start there!)

3. What’s the first small feature to extract? (Users? Products? Orders?)

4. Does it pass the tests? (Elevator pitch / Can it live alone)

Share in the comments. Let’s learn together.

Part 4 of the Page-Feature Composition series. Follow along at better-frontend.dev for practical Angular architecture.

Previous: PFC #3 - Building Features
Next: PFC #5 - Real-World Examples

This concludes the Page-Feature Composition series. Follow better-frontend.dev for more practical Angular architecture insights.

The Series:
- PFC #1 - The Philosophy
- PFC #2 - Pages as Orchestrators
- PFC #3 - Building Features
- PFC #4 - Migration Strategies ← You are here
- PFC #5 - Real-World Examples

Features are self-contained mini-applications. Use the container/component pattern (smart/dumb), expose a clean facade, keep internal services private, and manage state with NgRx or signals. Only export what pages need via index.ts. This structure makes features truly reusable across different page contexts without modification.

In PFC #1, we learned the philosophy. In PFC #2, we mastered page orchestration. Now it’s time for the main event: building features that actually work.

This is where the rubber meets the road. Get feature architecture right, and your app scales beautifully. Get it wrong, and you’re back to the spaghetti code we’re trying to escape.

Series Context: This is Part 3 of the Page-Feature Composition series. Parts 1 and 2 covered the “why” and “how pages work.” This post is all about “how features work internally.”

The Feature Mission

A feature has one job: to own a complete business capability.

Not “render a card.” Not “call an API.” Own the entire user management capability. Or product catalog. Or order processing. Everything related to that domain lives in one place.

What Makes a Good Feature?

• Self-contained - Everything it needs lives inside the feature folder

• Focused - One business domain, not “everything users-related ever”

• Reusable - Works in different page contexts without modification

• Testable - Can be tested in isolation

• Encapsulated - Internal details hidden from pages

Think of features as npm packages you could theoretically publish. They should be that independent.

Feature Anatomy

Let’s break down a real feature structure:

features/user-management/
├── components/                    # Dumb UI
│   ├── user-card/
│   │   ├── user-card.component.ts
│   │   ├── user-card.component.html
│   │   └── user-card.component.scss
│   └── user-form/
├── containers/                    # Smart orchestrators
│   └── user-management-container/
│       ├── user-management.container.ts
│       └── user-management.html
├── services/                      # Feature-specific services
│   └── user-api.service.ts
├── store/                         # State management
│   ├── actions.ts
│   ├── reducers.ts
│   ├── selectors.ts
│   ├── effects.ts
│   └── facade.ts                  # Internal store wrapper
├── models/
│   └── user.interface.ts
├── user-management.facade.ts      # PUBLIC API
├── user-management.module.ts
└── index.ts                       # Public exports only

Each folder has a specific purpose. Let’s explore them.

Containers vs Components

This is the heart of feature architecture. Get this right, and everything else falls into place.

Containers (Smart Components)

Containers orchestrate feature logic. They know about services, state, and business rules.

// src/app/features/user-management/containers/user-management-container/user-management.container.ts
import { Component, OnInit } from ‘@angular/core’;
import { Observable } from ‘rxjs’;

import { User } from ‘../../models/user.interface’;
import { UserStoreFacade } from ‘../../store/facade’;

@Component({
  selector: ‘app-user-management-container’,
  templateUrl: ‘./user-management.html’
})
export class UserManagementContainer implements OnInit {
  users$: Observable<User[]> = this.storeFacade.users$;
  isLoading$: Observable<boolean> = this.storeFacade.isLoading$;
  
  constructor(private storeFacade: UserStoreFacade) {}
  
  ngOnInit(): void {
    this.storeFacade.loadUsers();
  }
  
  onUserSelect(user: User): void {
    this.storeFacade.selectUser(user.id);
  }
  
  onUserDelete(user: User): void {
    if (confirm(`Delete ${user.name}?`)) {
      this.storeFacade.deleteUser(user.id);
    }
  }
}

Container responsibilities:

• Fetch data via services/store

• Handle user interactions (clicks, form submits)

• Manage feature-level state

• Coordinate multiple components

• Expose observables to the template

One container per feature is usually enough. Sometimes you need two to three for complex features, but that’s rare.

Components (Dumb/Presentational)

Components render UI. No services, no state, just inputs and outputs.

// src/app/features/user-management/components/user-card/user-card.component.ts
import { Component, EventEmitter, Input, Output } from ‘@angular/core’;
import { User } from ‘../../models/user.interface’;

@Component({
  selector: ‘app-user-card’,
  templateUrl: ‘./user-card.component.html’,
  styleUrls: [’./user-card.component.scss’]
})
export class UserCardComponent {
  @Input() user: User;
  @Input() showActions = true;
  
  @Output() select = new EventEmitter<User>();
  @Output() delete = new EventEmitter<User>();
  
  onSelect(): void {
    this.select.emit(this.user);
  }
  
  onDelete(): void {
    this.delete.emit(this.user);
  }
}

<!-- user-card.component.html -->
<div class=”user-card” (click)=”onSelect()”>
  <img [src]=”user.avatar” [alt]=”user.name”>
  <div class=”user-info”>
    <h3>{{ user.name }}</h3>
    <p>{{ user.email }}</p>
  </div>
  <button 
    *ngIf=”showActions”
    (click)=”onDelete(); $event.stopPropagation()”
    class=”delete-btn”>
    Delete
  </button>
</div>

Component responsibilities:

• Render UI based on inputs

• Emit events on user interactions

• Apply styling

• Stay dumb and reusable

The Golden Rule: If a component injects a service, it’s not dumb anymore. Make it a container or refactor.

The Template (Container)

<!-- user-management.html -->
<div class=”user-management”>
  <div class=”loading” *ngIf=”isLoading$ | async”>
    Loading users...
  </div>
  
  <div class=”user-list” *ngIf=”!(isLoading$ | async)”>
    <app-user-card
      *ngFor=”let user of users$ | async”
      [user]=”user”
      [showActions]=”true”
      (select)=”onUserSelect($event)”
      (delete)=”onUserDelete($event)”>
    </app-user-card>
  </div>
</div>

Container template coordinates components. That’s it.

The Facade Pattern

This is crucial. Every feature needs two facades:

Internal Store Facade (Private)

Wraps your state management (NgRx, signals, services). Used by containers inside the feature.

// src/app/features/user-management/store/facade.ts
import { Injectable } from ‘@angular/core’;
import { Store } from ‘@ngrx/store’;
import { Observable } from ‘rxjs’;

import { User } from ‘../models/user.interface’;
import * as userActions from ‘./actions’;
import * as userSelectors from ‘./selectors’;
import { State } from ‘./reducers’;

@Injectable({ providedIn: ‘root’ })
export class UserStoreFacade {
  readonly users$: Observable<User[]> = this.store.select(userSelectors.selectUsers);
  readonly isLoading$: Observable<boolean> = this.store.select(userSelectors.selectIsLoading);
  readonly selectedUser$: Observable<User | null> = this.store.select(userSelectors.selectSelectedUser);

  constructor(private store: Store<State>) {}

  loadUsers(): void {
    this.store.dispatch(userActions.loadUsers());
  }
  
  selectUser(userId: string): void {
    this.store.dispatch(userActions.selectUser({ userId }));
  }
  
  deleteUser(userId: string): void {
    this.store.dispatch(userActions.deleteUser({ userId }));
  }
}

Not exported. Containers use this directly.

External Feature Facade (Public)

Simple API for pages. Wraps the internal facade.

// src/app/features/user-management/user-management.facade.ts
import { Injectable } from ‘@angular/core’;
import { Observable } from ‘rxjs’;

import { UserStoreFacade } from ‘./store/facade’;

@Injectable()
export class UserManagementFacade {
  readonly isLoading$: Observable<boolean> = this.storeFacade.isLoading$;
  
  constructor(private storeFacade: UserStoreFacade) {}
  
  // Pages can call these if needed
  loadUsers(): void {
    this.storeFacade.loadUsers();
  }
  
  refreshUsers(): void {
    this.storeFacade.loadUsers();
  }
}

This gets exported. Pages can use it for programmatic actions.

Why Two Facades?

Separation of concerns:

• Internal facade = feature implementation details

• External facade = public API contract

Flexibility:

• Change internal state management (NgRx → signals) without breaking pages

• Internal facade can be complex

• External facade stays simple

Encapsulation:

• Pages only see what you want them to see

• Internal complexity hidden

State Management

You have options. Pick what fits your needs.

Option 1: NgRx (Recommended for Complex Features)

Complete state management with actions, reducers, effects, selectors.

// store/actions.ts
export const loadUsers = createAction(’[User Management] Load Users’);
export const loadUsersSuccess = createAction(
  ‘[User Management] Load Users Success’,
  props<{ users: User[] }>()
);

// store/reducers.ts
export const reducer = createReducer(
  initialState,
  on(loadUsers, state => ({ ...state, loading: true })),
  on(loadUsersSuccess, (state, { users }) => ({ ...state, users, loading: false }))
);

// store/effects.ts
loadUsers$ = createEffect(() =>
  this.actions$.pipe(
    ofType(loadUsers),
    switchMap(() =>
      this.userApi.getUsers().pipe(
        map(users => loadUsersSuccess({ users })),
        catchError(error => of(loadUsersFailure({ error })))
      )
    )
  )
);

Use when:

• Complex state with multiple data sources

• Need time-travel debugging

• Large team wants predictable patterns

Option 2: Signals (Simpler Alternative)

Angular 16+ signals for reactive state.

// store/user.store.ts
@Injectable({ providedIn: ‘root’ })
export class UserStore {
  private usersSignal = signal<User[]>([]);
  private loadingSignal = signal(false);
  
  readonly users = this.usersSignal.asReadonly();
  readonly isLoading = this.loadingSignal.asReadonly();
  
  constructor(private userApi: UserApiService) {}
  
  loadUsers(): void {
    this.loadingSignal.set(true);
    this.userApi.getUsers().subscribe(users => {
      this.usersSignal.set(users);
      this.loadingSignal.set(false);
    });
  }
}

Use when:

• Simpler state needs

• Want less boilerplate

• Working with Angular 16+

Option 3: Service with BehaviorSubject

Classic reactive service pattern.

// services/user-state.service.ts
@Injectable({ providedIn: ‘root’ })
export class UserStateService {
  private usersSubject = new BehaviorSubject<User[]>([]);
  private loadingSubject = new BehaviorSubject(false);
  
  readonly users$ = this.usersSubject.asObservable();
  readonly isLoading$ = this.loadingSubject.asObservable();
  
  constructor(private userApi: UserApiService) {}
  
  loadUsers(): void {
    this.loadingSubject.next(true);
    this.userApi.getUsers().subscribe(users => {
      this.usersSubject.next(users);
      this.loadingSubject.next(false);
    });
  }
}

Use when:

• Simple features

• Don’t want NgRx overhead

• Familiar RxJS patterns

Pick one per feature. Don’t mix approaches within a single feature.

Services

Feature-specific services stay private.

// services/user-api.service.ts
import { Injectable } from ‘@angular/core’;
import { HttpClient } from ‘@angular/common/http’;
import { Observable } from ‘rxjs’;

import { User } from ‘../models/user.interface’;

@Injectable({ providedIn: ‘root’ })
export class UserApiService {
  private apiUrl = ‘/api/users’;
  
  constructor(private http: HttpClient) {}
  
  getUsers(): Observable<User[]> {
    return this.http.get<User[]>(this.apiUrl);
  }
  
  getUserById(id: string): Observable<User> {
    return this.http.get<User>(`${this.apiUrl}/${id}`);
  }
  
  deleteUser(id: string): Observable<void> {
    return this.http.delete<void>(`${this.apiUrl}/${id}`);
  }
}

Not exported. Only the store/state service uses this.

Public API (index.ts)

This is your feature’s contract with the outside world.

// src/app/features/user-management/index.ts
// Only export what pages need
export * from ‘./user-management.module’;
export * from ‘./user-management.facade’;

// Everything else stays private:
// ❌ UserStoreFacade
// ❌ UserApiService  
// ❌ UserCardComponent
// ❌ Store internals (actions, reducers, effects)
// ❌ Models (unless other features need them)

Golden rule: Export as little as possible. Pages should only see:

1. The module (to import)

2. The facade (for programmatic actions)

3. Maybe types if shared across features

That’s it.

The Module

// user-management.module.ts
import { NgModule } from ‘@angular/core’;
import { CommonModule } from ‘@angular/common’;
import { EffectsModule } from ‘@ngrx/effects’;
import { StoreModule } from ‘@ngrx/store’;

import { UserCardComponent } from ‘./components/user-card/user-card.component’;
import { UserManagementContainer } from ‘./containers/user-management-container/user-management.container’;
import { UserManagementFacade } from ‘./user-management.facade’;
import { UserEffects } from ‘./store/effects’;
import { featureKey, reducer } from ‘./store/reducers’;

@NgModule({
  imports: [
    CommonModule,
    EffectsModule.forFeature([UserEffects]),
    StoreModule.forFeature(featureKey, reducer)
  ],
  declarations: [
    UserCardComponent,
    UserManagementContainer
  ],
  exports: [
    UserManagementContainer  // Only export the container
  ],
  providers: [
    UserManagementFacade
  ]
})
export class UserManagementModule { }

Only export the container. Internal components stay private.

Feature Modes

Features should adapt to different contexts via inputs, not configuration.

@Component({
  selector: ‘app-user-management-container’,
  template: `...`
})
export class UserManagementContainer {
  @Input() mode: ‘full’ | ‘compact’ | ‘selection’ = ‘full’;
  @Input() maxItems?: number;
  @Input() showActions = true;
  
  @Output() userSelected = new EventEmitter<User>();
}

Usage on different pages:

<!-- Dashboard: compact view -->
<app-user-management-container 
  mode=”compact” 
  [maxItems]=”5”>
</app-user-management-container>

<!-- Admin: full view -->
<app-user-management-container 
  mode=”full”>
</app-user-management-container>

<!-- Selection dialog -->
<app-user-management-container 
  mode=”selection”
  (userSelected)=”handleSelection($event)”>
</app-user-management-container>

Same feature, different contexts. No code changes needed.

Common Mistakes

Mistake 1: Exporting Too Much

// ❌ DON’T
export * from ‘./components/user-card/user-card.component’;
export * from ‘./services/user-api.service’;
export * from ‘./store/actions’;

These couple of pages to your internals. Change implementation = break pages.

// ✅ DO
export * from ‘./user-management.module’;
export * from ‘./user-management.facade’;

Mistake 2: Smart Components

// ❌ DON’T: Component injecting services
export class UserCardComponent {
  constructor(private userService: UserApiService) {}
}

Components should be dumb. Move logic to the container.

// ✅ DO: Dumb component with inputs/outputs
export class UserCardComponent {
  @Input() user: User;
  @Output() delete = new EventEmitter<User>();
}

Mistake 3: Feature-to-Feature Dependencies

// ❌ DON’T: Feature importing another feature
import { ProductCatalogFacade } from ‘../product-catalog’;

Features should be independent. If they need to communicate, let the page coordinate.

Mistake 4: No Facade

// ❌ DON’T: Exporting store directly
export * from ‘./store/facade’;

Always wrap internals in a feature facade. Gives you flexibility to change implementation.

Testing Strategy

Test Components in Isolation

describe(’UserCardComponent’, () => {
  it(’should emit select event on click’, () => {
    const component = new UserCardComponent();
    const user = { id: ‘1’, name: ‘John’ };
    component.user = user;
    
    spyOn(component.select, ‘emit’);
    component.onSelect();
    
    expect(component.select.emit).toHaveBeenCalledWith(user);
  });
});

Test Containers with Mocked Facade

describe(’UserManagementContainer’, () => {
  let facade: jasmine.SpyObj<UserStoreFacade>;
  
  beforeEach(() => {
    facade = jasmine.createSpyObj(’UserStoreFacade’, [’loadUsers’]);
  });
  
  it(’should load users on init’, () => {
    const container = new UserManagementContainer(facade);
    container.ngOnInit();
    
    expect(facade.loadUsers).toHaveBeenCalled();
  });
});

Test Feature Integration

describe(’UserManagementModule’, () => {
  it(’should render container with users’, async () => {
    const fixture = TestBed.createComponent(UserManagementContainer);
    // Test full feature behavior
  });
});

Clean architecture = easy testing.

The Feature Checklist

Before marking a feature “done”:

• Containers handle smart logic, components stay dumb

• Internal store facade wraps state management

• External feature facade provides a simple API

• Only the module and facade are exported via index.ts

• Services are private to the feature

• No dependencies on other features

• Container supports different modes via inputs

• All components have unit tests

• Feature works in isolation

Summary

Features are mini-applications. Get the internal structure right, and everything else becomes easy.

Key takeaways:

✅ Use container/component pattern (smart/dumb)
✅ Two facades: internal (store) + external (feature)
✅ Pick one state approach per feature (NgRx/signals/service)
✅ Keep services private
✅ Export minimal API via index.ts
✅ Support multiple modes via inputs
✅ Test components and containers separately

Build features this way, and they’ll work beautifully on any page you compose them into.

What’s Next

PFC #4 - From Monolith to Composition
Practical migration strategies. How to adopt PFC in existing projects without rewriting everything. Team workflows and common pitfalls.

PFC #5 - Real-World Examples
Complete feature and page implementations working together. Dashboard example, form flows, and handling complex scenarios.

Your Challenge

Pick one feature from your current codebase:

1. Can you identify what should be containers vs components?

2. What would you expose via the facade?

3. What services should stay private?

4. How many “modes” does it need to support?

Share your analysis in the comments. Next week, we tackle migration strategies.

Part 3 of the Page-Feature Composition series. Follow along at better-frontend.dev for practical Angular architecture.

Previous: PFC #2 - Pages as Orchestrators
Next: PFC #4 - Migration Strategies

This concludes the Page-Feature Composition series. Follow better-frontend.dev for more practical Angular architecture insights.

The Series:
- PFC #1 - The Philosophy
- PFC #2 - Pages as Orchestrators
- PFC #3 - Building Features ← You are here
- PFC #4 - Migration Strategies
- PFC #5 - Real-World Examples

Pages are conductors, not implementers. They compose features into user experiences through simple templates, handle navigation and routing, and manage feature-to-feature communication when needed. Keep pages under 50 lines of TypeScript by letting features own all business logic.

In PFC #1, we introduced the core philosophy: separate features (business logic) from pages (orchestration). Now, let’s dive deep into how pages actually work as orchestrators.

Remember that messy 200-line page component mixing users, products, and orders? By the end of this post, you’ll know exactly how to break it down into a clean, composable architecture.

Series Context: This is Part 2 of the Page-Feature Composition series. New here? Start with PFC #1 to understand the foundation.

The Conductor Mindset

Think about a symphony orchestra. The conductor doesn’t play violin, trumpet, or drums. They coordinate musicians to create a cohesive performance.

Pages work the same way. They don’t implement user management, product catalogs, or order processing. They coordinate features to create user experiences.

What Pages Should Do

✅ Compose features - Arrange feature containers on the screen
✅ Handle navigation - Respond to route changes and manage routing
✅ Coordinate communication - Pass data between features when needed
✅ Apply layout - Structure the page visually
✅ Manage route-specific state - Track active tab, scroll position, etc.

What Pages Should NOT Do

❌ Business logic - That belongs in features
❌ API calls - Features handle their own data
❌ Complex state management - Features manage their own state
❌ Component implementation - Use feature containers, don’t build inline

Golden rule: If your page component has more than 50 lines of TypeScript, something probably belongs in a feature.

Page Anatomy

A typical page is mostly template, minimal code:

// src/app/pages/dashboard/dashboard.page.ts
@Component({
  templateUrl: ‘./dashboard.html’,
  styleUrls: [’./dashboard.scss’]
})
export class DashboardPage {
  constructor(private router: Router) {}
  
  navigateToUserDetail(userId: string): void {
    this.router.navigate([’/users’, userId]);
  }
}

That’s eight lines. The template does the heavy lifting:

<!-- src/app/pages/dashboard/dashboard.html -->
<div class=”dashboard-grid”>
  <section class=”users-section”>
    <h2>Team Overview</h2>
    <app-user-management-container 
      mode=”compact”
      [maxItems]=”8”>
    </app-user-management-container>
  </section>
  
  <section class=”products-section”>
    <h2>Latest Products</h2>
    <app-product-catalog-container 
      mode=”summary”>
    </app-product-catalog-container>
  </section>
</div>

The template is declarative. It says, “Put user management here, products there.” That’s orchestration.

Composition Patterns

Let’s explore the most common patterns for composing features.

Pattern 1: Grid Layout

Multiple features arranged in a grid. The most common pattern.

<div class=”grid-layout”>
  <div class=”grid-item span-2”>
    <app-user-management-container mode=”compact”></app-user-management-container>
  </div>
  
  <div class=”grid-item”>
    <app-notifications-container></app-notifications-container>
  </div>
  
  <div class=”grid-item span-3”>
    <app-analytics-container></app-analytics-container>
  </div>
</div>

Grid styling in CSS. Features just get composed.

Pattern 2: Tabs

Different features on different tabs. Page manages which tab is active.

export class AdminPage {
  activeTab = ‘users’;
}

<nav class=”tabs”>
  <button (click)=”activeTab = ‘users’”>Users</button>
  <button (click)=”activeTab = ‘products’”>Products</button>
</nav>

<app-user-management-container *ngIf=”activeTab === ‘users’”></app-user-management-container>
<app-product-catalog-container *ngIf=”activeTab === ‘products’”></app-product-catalog-container>

Tab state lives on the page. Features don’t know about tabs.

Pattern 3: Master-Detail

One feature drives what another displays.

export class CustomerPortalPage {
  selectedUserId: string | null = null;
}

<div class=”master-detail”>
  <aside class=”master”>
    <app-user-list-container 
      (userSelected)=”selectedUserId = $event”>
    </app-user-list-container>
  </aside>
  
  <main class=”detail”>
    <app-user-detail-container 
      *ngIf=”selectedUserId”
      [userId]=”selectedUserId”>
    </app-user-detail-container>
  </main>
</div>

User list emits selection. Page coordinates are passed to the detail view.

Pattern 4: Multi-Step Flow

A wizard with different features at each step.

export class OnboardingPage {
  currentStep = 1;
}

<div class=”steps”>Step {{currentStep}} of 3</div>

<app-profile-form-container 
  *ngIf=”currentStep === 1”
  (completed)=”currentStep = 2”>
</app-profile-form-container>

<app-preferences-container 
  *ngIf=”currentStep === 2”
  (completed)=”currentStep = 3”>
</app-preferences-container>

Step management is a page concern. Each step is a feature.

Feature Communication

Sometimes, features need to communicate with each other. The page coordinates.

Simple: Through the Page

export class SalesDashboardPage {
  selectedDateRange: DateRange | null = null;
}

<app-date-picker-container 
  (dateRangeChanged)=”selectedDateRange = $event”>
</app-date-picker-container>

<app-sales-chart-container 
  [dateRange]=”selectedDateRange”>
</app-sales-chart-container>

Date picker emits. Page passes to the chart. Simple and explicit.

Advanced: Using Facades

When you need to trigger actions programmatically:

export class ProductManagementPage implements OnInit {
  constructor(
    private route: ActivatedRoute,
    private productFacade: ProductCatalogFacade
  ) {}
  
  ngOnInit(): void {
    this.route.params.subscribe(params => {
      if (params[’category’]) {
        this.productFacade.filterByCategory(params[’category’]);
      }
    });
  }
}

Page responds to routes and triggers feature actions via the facade. Container still handles the UI.

Common Mistakes

Mistake 1: Business Logic in Pages

Don’t do this:

export class DashboardPage {
  users: User[] = [];
  
  ngOnInit() {
    this.userService.getUsers().subscribe(users => {
      this.users = users.filter(u => u.active);
    });
  }
}

Do this instead:

export class DashboardPage {
  // Just compose features in template
}

Let the user-management feature handle users.

Mistake 2: Tightly Coupled Features

Don’t do this:

<app-user-list [detailComponentRef]=”userDetail”></app-user-list>
<app-user-detail #userDetail></app-user-detail>

Features shouldn’t know about each other.

Do this instead:

<app-user-list (userSelected)=”selectedId = $event”></app-user-list>
<app-user-detail [userId]=”selectedId”></app-user-detail>

Page coordinates the connection.

Mistake 3: Complex Page State

Don’t do this:

export class DashboardPage {
  userFilters = { ... };
  productFilters = { ... };
  sortOptions = { ... };
  // 50 more properties
}

Do this instead:

export class DashboardPage {
  activeTab = ‘overview’; // Minimal page state only
}

Filters and sort belong in features, not pages.

Real Example

Here’s what a real admin dashboard looks like with PFC:

// 15 lines total
export class AdminDashboardPage {
  constructor(private router: Router) {}
  
  onUserSelected(userId: string): void {
    this.router.navigate([’/users’, userId]);
  }
}

<!-- Template composes 4 features -->
<div class=”dashboard-grid”>
  <section class=”stats”>
    <app-analytics-container mode=”summary”></app-analytics-container>
  </section>
  
  <section class=”users”>
    <h2>Recent Users</h2>
    <app-user-management-container 
      mode=”compact”
      (userSelected)=”onUserSelected($event)”>
    </app-user-management-container>
  </section>
  
  <section class=”products”>
    <h2>Top Products</h2>
    <app-product-catalog-container mode=”summary”></app-product-catalog-container>
  </section>
  
  <section class=”activity”>
    <app-activity-feed-container></app-activity-feed-container>
  </section>
</div>

Total TypeScript: 15 lines
Features composed: 4 (analytics, users, products, activity)
Business logic in page: 0

Clean, maintainable, testable.

The Page Checklist

Before you mark a page “done,” ask yourself:

• Is the TypeScript file under 50 lines?

• Does it contain zero business logic?

• Are all API calls in features, not the page?

• Is state management delegated to features?

• Are feature containers doing the heavy lifting?

• Is the template declarative and easy to scan?

If you answered “no” to any of these, refactor something into a feature.

Summary

Pages as orchestrators are the foundation of PFC. Keep them lean and focused on composition.

Key takeaways:

✅ Pages compose features via templates
✅ Keep TypeScript under 50 lines
✅ Handle navigation and routing only
✅ Coordinate feature communication when needed
✅ Let features own all business logic
✅ Use composition patterns (grid, tabs, master-detail, steps)

The beauty of this approach? Six months from now, you’ll open a page file and instantly understand what it does. No archaeological dig required.

What’s Next

PFC #3 - Building Bulletproof Features
Internal feature architecture. Containers vs components, the facade pattern, state management, and what to export vs keep private.

PFC #4 - From Monolith to Composition
Practical migration strategies. How to adopt PFC in existing projects without rewriting everything. Team workflows and common pitfalls.

PFC #5 - Real-World Examples
Complete feature and page implementations working together. Dashboard example, form flows, and handling complex scenarios.

Your Challenge

Look at one of your current page components:

1. How many lines of TypeScript does it have?

2. How much of that could move into features?

3. Which composition pattern would work best?

Share your findings in the comments. Next week, we’ll build features the right way.

Part 2 of the Page-Feature Composition series. Follow along at better-frontend.dev for practical Angular architecture.

Previous: PFC #1 - The Philosophy
Next: PFC #3 - Building Features

This concludes the Page-Feature Composition series. Follow better-frontend.dev for more practical Angular architecture insights.

The Series:
- PFC #1 - The Philosophy
- PFC #2 - Pages as Orchestrators ← You are here
- PFC #3 - Building Features
- PFC #4 - Migration Strategies
- PFC #5 - Real-World Examples

Why Angular projects turn into spaghetti and how to fix it

TL;DR

Traditional Angular projects tend to become spaghetti-like as they grow. Components get tightly coupled to contexts. Copy-paste becomes the norm. PFC fixes this by separating Features (business logic) from Pages (orchestration). Result: truly reusable features, cleaner code, happier teams. While this series focuses on Angular, the core concepts apply to React, Vue, and any other component-based framework.

Six months ago, your Angular project was a thing of beauty. Clean components, organized services, everything in its place. Today? You’re afraid to touch anything because changing one component might break three others you didn’t know existed.

Sound familiar? You’re not alone. Every Angular developer has been there.

If that describes your current situation, you’re about to meet your new best friend: Page-Feature Composition. It’s not rocket science, it’s not revolutionary. It’s just a sensible way to organize frontend apps that actually scales.

Note: This series uses Angular and TypeScript for examples, but the architecture patterns work with React, Vue, Svelte, or any component-based framework. The principles are framework-agnostic; the syntax is Angular.

The Philosophy

Stop fighting Angular and start working with it. The key insight is simple: stop asking “How do I make this component reusable everywhere?” and start asking “How do I make features composable on pages?”

The Problem We Keep Creating

// We’ve all written this
@Component({
  selector: ‘app-user-card’,
  template: `...`
})
export class UserCardComponent {
  @Input() user: User;
  
  constructor(
    private userService: UserService,
    private router: Router
  ) {}
  
  editUser() {
    this.router.navigate([’/admin/users/edit’, this.user.id]);
  }
}

This looks innocent enough. Until six months later, when you need the same card in a customer dashboard, but it navigates to the wrong route. Now you’re adding props to control routes, actions, and styling.

Welcome to prop hell. Population: your entire codebase.

The Mental Shift

The difference? Components try to be generic (and fail). Features are specific but composable. Pages orchestrate features into different contexts without modifying them.

Folder Structure

Here’s how PFC organizes an Angular project:

src/app/
├── features/              # Business logic lives here
│   ├── user-management/
│   ├── product-catalog/
│   └── order-processing/
├── pages/                 # Orchestrators
│   ├── dashboard/
│   ├── admin/
│   └── customer-portal/
├── shared/                # Utilities
│   └── components/
└── core/                  # App foundation
    └── auth/

Features

Self-contained business capabilities. Everything related to “user management” lives in one folder. Components, services, state management, all of it. Think of features as mini-applications focused on a single business domain.

Pages

Conductors that compose features into user experiences but contain zero business logic. Just orchestration. A page arranges features on screen and handles navigation.

Shared

Truly generic stuff. Button components, pipes, utilities that work anywhere. If it doesn’t belong to a specific feature and isn’t page-specific, it should be placed here.

Core

App-wide concerns. Authentication, layout, configuration. Things that are truly global to your application.

Pages as Orchestrators

This is the key insight that makes everything fall into place. Pages don’t implement features. They compose them.

Think of a symphony orchestra. The conductor doesn’t play the instruments. They coordinate the musicians (features) to create a cohesive performance (user experience).

What You’re Probably Doing Now

Your page component contains over 200 lines of template code that mixes users, products, orders, and notifications. The TypeScript file contains over 50 properties and methods that handle everything.

It’s a kitchen sink. Nobody wants to touch it because changing one thing might break three others.

The PFC Way

// src/app/pages/dashboard/dashboard.page.ts
@Component({
  templateUrl: ‘./dashboard.html’
})
export class DashboardPage { }

<!-- src/app/pages/dashboard/dashboard.html -->
<div class=”dashboard-grid”>
  <section class=”users-section”>
    <h2>Team Overview</h2>
    <app-user-management-container></app-user-management-container>
  </section>
  
  <section class=”products-section”>
    <h2>Latest Products</h2>
    <app-product-catalog-container></app-product-catalog-container>
  </section>
</div>

The page is almost empty. It just arranges features on the screen and adds page-specific layout.

• User logic? Lives in the user-management feature.

• Product logic? Lives in the product-catalog feature.

• Dashboard layout? That’s the page’s only job.

Clean separation. Clear boundaries. No confusion about where code belongs.

Features Architecture

Each feature is a mini-application focused on one business domain. This is where the real work happens.

Internal Structure

features/user-management/
├── components/            # Dumb UI (user cards, forms)
├── containers/            # Smart orchestrators
├── services/              # API calls
├── store/                 # State management (NgRx/signals)
├── models/                # TypeScript interfaces
├── user-management.facade.ts     # Public API
├── user-management.module.ts
└── index.ts               # What pages can use

The magic is in what you export vs what stays internal.

Public vs Private API

// src/app/features/user-management/index.ts
export * from ‘./user-management.module’;
export * from ‘./user-management.facade’;

// Everything else stays private:
// - Internal components
// - Services
// - Store details
// - Helper utilities

Pages can only access what you explicitly export. This prevents tight coupling and keeps your architecture clean.

The Facade Pattern

Each feature exposes a facade. It’s a simple API that pages can use to trigger feature actions programmatically.

// src/app/features/user-management/user-management.facade.ts
@Injectable()
export class UserManagementFacade {
  readonly isLoading$ = this.storeFacade.isLoading$;
  
  constructor(private storeFacade: UserStoreFacade) {}
  
  loadUsers(): void {
    this.storeFacade.loadUsers();
  }
}

Most of the time, pages use the container component and never interact with the facade. But it’s there when you need it (like programmatically refreshing data or responding to route changes).

Why This Works

After using PFC in production for over a year on real enterprise applications, here’s what we’ve learned:

For Your Code

• True reusability. The user-management container works on the dashboard, admin panel, and customer portal. Same code, different contexts. No modifications needed.

• Clear boundaries. No more “where does this file go?” debates. User stuff goes in features/user-management/. The dashboard page goes in pages/dashboard/. Done.

• Easy testing. Test features in isolation with simple input and output values. Test pages as composition exercises. No massive mock setups required.

• Predictable growth. Your codebase grows linearly with features, not exponentially. Adding feature 20 doesn’t make features 1-19 more complex.

For Your Team

• Parallel development. Developer A builds the user-management feature. Developer B builds the product-catalog feature. Developer C composes them into pages. Minimal merge conflicts.

• Fast onboarding. New developers understand the pattern in 10 minutes. “Features contain business logic. Pages compose features. That’s it.”

• Scales with team size. Works great for solo developers (clear structure). Scales perfectly to large teams (clear ownership).

For Your Sanity

• No prop explosion. Features handle their own modes and configurations internally. No 15+ optional props trying to make components “generic.”

• No copy-paste hell. Build the feature once, compose it everywhere. The user-management feature is the same whether it’s on page 1 or page 10.

• No modification fear. Changing a feature doesn’t randomly break unrelated pages. Clear boundaries mean predictable impact.

When NOT to Use PFC

Let’s be honest. This isn’t always the answer:

Skip it for:

• Simple landing pages or marketing sites

• Prototypes or short-term experiments

• Solo projects under 10 routes

• Apps with mostly unique, one-off interfaces

Use it for:

• Medium to large applications (10+ routes)

• Long-term projects that will evolve

• Teams of 3+ developers

• Apps with recurring UI patterns

What’s Next

This post introduced the philosophy and high-level structure. We’ll dive deeper in upcoming posts:

PFC #2 - Pages as Orchestrators
How to compose features without losing your mind. Real composition patterns, handling feature communication, and layout strategies.

PFC #3 - Building Bulletproof Features
Internal feature architecture. Containers vs components, the facade pattern, state management, and what to export vs keep private.

PFC #4 - From Monolith to Composition
Practical migration strategies. How to adopt PFC in existing projects without rewriting everything. Team workflows and common pitfalls.

PFC #5 - Real-World Examples
Complete feature and page implementations working together. Dashboard example, form flows, and handling complex scenarios.

Your Mission

Before the next post drops, audit your current Angular project:

1. Find your most complex page component. How many lines? How many different business concerns does it handle?

2. Count your component variations. How many “Card” components do you have? UserCard, ProductCard, CustomerCard, EmployeeCard...

3. Identify feature boundaries. What natural business groupings exist? What chunks of functionality could be self-contained?

Drop a comment and share what you find. Don’t be shy about the mess. We’ve all been there, and that’s precisely where PFC shines brightest.

Bonus challenge: Try to identify one feature in your current codebase that could be extracted using PFC principles. What would you put in the feature folder? What would the facade expose?

This is Part 1 of the Page-Feature Composition (PFC) series. Follow along at better-frontend.dev for practical Angular wisdom that keeps your projects clean and your coffee breaks peaceful.

Next up: PFC #2 - Pages as Orchestrators

This concludes the Page-Feature Composition series. Follow better-frontend.dev for more practical Angular architecture insights.

The Series:
- PFC #1 - The Philosophy ← You are here
- PFC #2 - Pages as Orchestrators
- PFC #3 - Building Features
- PFC #4 - Migration Strategies
- PFC #5 - Real-World Examples

What Actually Is BlackDuck?

BlackDuck is your npm package security detective. It’s SCA software that does three important things when you’re building that Next.js app:

• Identifies everything in your dependency tree, including those sneaky transitive dependencies you never meant to install but are in node_modules anyway.

• Finds known vulnerabilities by scanning across your entire dependency tree (much smarter than npm audit).

• Tracks license compliance since that seemingly innocent React component may have a GPL license that requires you to open source your entire commercial application.

Here’s a reality check: 97% of all applications contain open source software, with most components coming from npm. That React app you’re creating? BlackDuck is keeping track of everything.

Why This Matters for Frontend Devs

The npm Ecosystem Reality

Frontend development is like assembling LEGO blocks from npm. We pull in packages for everything, such as date formatting, UI components, and HTTP requests, often without thinking about what we’re actually installing. The average React application includes hundreds, sometimes thousands, of dependencies when you consider the entire tree.

Many JavaScript applications have at least one known vulnerability in their dependencies. This isn’t made up; real vulnerability research shows that it’s common across the ecosystem. Most React apps operate with publicly documented security flaws.

The Transitive Dependency Problem

Here’s the scary part: 64% of open source components are transitive dependencies: libraries that other libraries rely on. You install one component, and suddenly you have fifty new packages in your node_modules that you never actually chose.

This is where npm ls becomes very helpful. It displays the complete dependency tree, helping you identify which of your direct dependencies introduced the problematic code. But manually tracking vulnerabilities across hundreds of transitive dependencies? That’s where BlackDuck saves you hours of work.

Real Attacks, Real Damage

The event-stream incident (2018): A popular npm package downloaded millions of times each week was compromised with malicious code aimed at stealing cryptocurrency.

The ua-parser-js attack: A widely used library for parsing user agent strings was hijacked to install cryptocurrency miners and steal passwords.

These weren’t hypothetical vulnerabilities in forgotten documentation; they were actual attacks targeting real JavaScript applications with real users. BlackDuck helps identify which of your apps were affected via their dependency chains.

How BlackDuck Works with Modern Frontend

Understanding Your JavaScript Dependencies

BlackDuck doesn’t just scan your package.json. It thoroughly analyzes your entire dependency tree, including nested dependencies that you may not have installed. When working with React, Next.js, or Vue, BlackDuck identifies components using several methods: scanning package manifests, analyzing bundled JavaScript files, and checking Docker containers if you deploy that way.

The Knowledge Base

BlackDuck maintains the KnowledgeBase, a massive database of over 7.8 million open-source components, with a particular strength in JavaScript. They track npm packages, their version histories, known vulnerabilities, and license obligations. This database is continuously updated, often identifying vulnerabilities in popular frontend libraries weeks before they are reported in official CVE databases.

License Compliance (The Underrated Problem)

Open source doesn’t mean “free to use however you want.” Many JavaScript libraries come with license conditions. Some require attribution notices. Others, such as GPL-licensed packages, may require you to open-source your entire commercial application if you use them.

BlackDuck tracks over 2,500 different license types and their obligations. This is especially important in frontend development, where bundling and minification can accidentally strip necessary license notices.

Practical Implementation for React & Next.js

Start Simple: Scan Your Existing Projects

You don’t need to change your workflow immediately. Direct BlackDuck at your frontend project and let it analyze what you’re currently using. For a typical Next.js application, you’ll receive a comprehensive report detailing all dependencies, their licenses, and any known security issues.

Think of it as a health check for your codebase. You may be surprised by what’s hidden in your dependency tree.

Use npm ls as your Swiss Army Knife.

Before diving into BlackDuck’s advanced features, get familiar with npm ls. This built-in command shows your exact dependency tree. When BlackDuck points out a vulnerability in a transitive dependency, npm ls helps you trace back to see which of your direct dependencies introduced it, making remediation straightforward.

npm ls [package-name]

This command tells you precisely which package to update or replace.

Focused Remediation Strategy

Start with direct dependencies first: When BlackDuck flags issues, prioritize packages you directly installed. You have more control over replacing or updating them compared to transitive dependencies.

Understand the impact of your bundle: Not all dependencies are the same. A vulnerability in a build-time tool, such as Webpack, might be less critical than one in a runtime library shipped to browsers. BlackDuck helps you understand which components actually make it into your final bundle.

Leverage the JavaScript ecosystem: The npm ecosystem is rich with alternatives. If BlackDuck flags an issue with your date manipulation library, switching to an alternative (such as date-fns, dayjs, or luxon) may be quicker than waiting for a patch.

Set Intelligent Policies, Not Panic

Configure BlackDuck to focus on what matters most for frontend applications. High and critical CVSS scores in packages handling user input or authentication require immediate attention. A medium-severity vulnerability in a development dependency that never reaches production can be addressed in the next maintenance cycle.

BlackDuck also tracks whether vulnerabilities have known exploits in the wild. A theoretical security flaw is different from one that attackers are actively exploiting.

Investigation and Resolution

Where to Research JavaScript Vulnerabilities

When BlackDuck flags a vulnerability in your React application, start with the package’s GitHub repository for security announcements, patch releases, or community discussions. Most JavaScript maintainers respond well to security concerns and provide detailed explanations of the impact.

The npm security advisory database is another valuable resource for understanding how vulnerabilities affect different usage patterns. Sometimes security issues only appear when you use a library in specific ways, so knowing the attack vector helps you assess your actual risk.

Frontend-Specific Remediation

Update dependencies gradually: Unlike backend services, frontend applications often have complex dependency interactions. Update packages incrementally and test thoroughly, especially for significant version changes.

Commit your lock files: Your package-lock.json or yarn.lock files are critical for security. They ensure production builds use the identical versions of dependencies as development. When you update packages to fix vulnerabilities, commit the updated lock files to maintain consistency.

Test across browsers: Frontend vulnerabilities can behave differently in different browser environments. When updating packages to address security issues, test your applications across multiple browsers and devices.

Integration with Your Existing Workflow

IDE and Editor Integration

Many development environments support BlackDuck integration directly in VS Code or your preferred IDE. This means you can view vulnerability information for packages directly in your editor without needing to change contexts.

This integration is beneficial when adding new dependencies. Instead of installing first and scanning later, you receive security information about packages before they are added to your package.json. It’s like having a security advisor watching over you while you code.

Works Alongside Your Current Tools

BlackDuck complements the tools you already use, such as npm audit, Snyk, Renovate, or Dependabot. Each tool has its own strengths, and combining them provides better coverage than relying on any single solution.

If you’re already using dependency management automation, BlackDuck offers additional context for suggested updates. Instead of blindly accepting all dependency updates, you can prioritize those addressing security vulnerabilities or license issues.

Make It Part of Code Reviews

BlackDuck’s findings should be included in your code review discussions. If someone adds a new dependency to your React application, the review can encompass its security profile and license implications, in addition to its functionality.

This normalizes security considerations alongside code quality factors, such as linting and testing. You wouldn’t ship code with syntax errors or failing tests; you shouldn’t ship code with known security vulnerabilities when practical alternatives exist.

The Practical Reality

Security isn’t a one-time checkbox. It’s about continuous improvement rather than achieving perfect protection, which doesn’t exist.

Focus on understanding your dependency tree. Make informed decisions about acceptable risks for your applications and establish processes to address issues as they arise. The JavaScript ecosystem moves quickly. New vulnerabilities are regularly discovered.

Instead of trying to stay ahead of every possible issue, build good practices around dependency management and security scanning. BlackDuck provides the visibility and information you need to make informed decisions for your frontend applications.

Next time someone mentions BlackDuck in a meeting, you’ll know exactly what it does and why it matters. More importantly, you’ll understand how to use it effectively to build better, more secure applications for your users.

In development, learning doesn’t have to feel like a burden or just a step toward something else. When we make learning a daily habit, a journey instead of a destination, it adds enjoyment to our work and helps us grow. Let’s explore how maintaining a curious mindset can turn even repetitive days into something meaningful and exciting.

Learning as a Journey, Not a Goal

In the development world, there’s no finish line, and that’s part of what makes it great. We never really “finish” learning. Each new language, tool, or framework we learn opens up additional possibilities we didn’t even know existed. The best part? We get to choose where our curiosity leads us next. Instead of feeling pressured to learn everything or master the latest trend, let’s view it as a journey, with each step revealing new and interesting perspectives.

There’s no need to stress over what’s next or worry about falling behind. Embrace the journey as it comes and be open to discovering how much there is to learn.

Injecting Curiosity into the Everyday

Experimenting doesn’t always mean learning an entirely new stack or completely rebuilding your project. It’s often about those small, daily moments when curiosity sparks. Maybe you try a new way to organize your CSS, or you test a new VS Code extension to see if it improves your workflow. These little experiments are fun, they’re low stakes, but they can lead to small wins that make the day feel more productive and engaging.

Even in routine tasks, you can find simple ways to mix things up. Tinker with your process, and challenge yourself to make it faster, smoother, or just a bit more creative.

Stepping Outside Your Tech Comfort Zone

Now let’s discuss the exciting part: stepping outside our comfort zones. Sure, sticking to what we know feels safe, but it can also make work feel monotonous. If you’re a frontend developer, why not explore backend concepts? Or if you’re focused on web development, take a weekend to learn about the AI field.

Exploring beyond your usual tech stack is refreshing; it makes you a more versatile developer. Additionally, observing how other areas of the tech world operate can inspire new ideas and insights that you wouldn’t gain by staying in one lane. You may even find inspiration in unexpected places.

Making Curiosity a Habit, Not a To-Do

Curiosity grows when we nurture it, and making it a habit is easier than it seems. It doesn’t require us to sit for hours in “learning mode.” It’s more about finding small moments of curiosity throughout the day. Ask “why” when you see something done differently, dive deeper into topics that interest you, and don’t rush through tutorials to check them off your list.

These small habits help make learning feel less like a task and more like a natural part of your routine. It’s about letting your curiosity wander and following wherever it goes.

Playing Without Pressure

I understand, sometimes we think that if we’re learning something, it has to be immediately useful or relevant to the next big project. But the beauty of learning often comes from playing without pressure. Explore that new framework just because it interests you. Try building a little app without any intention of publishing it. Not every experiment requires a clear purpose. This freedom to play unencumbered by expectations is where real growth happens.

When you let yourself learn without expecting a specific outcome, you open up to greater creativity and a deeper understanding. And if it doesn’t lead anywhere, that’s okay. It was still worthwhile because it added to your skills.

Exploring Different Worlds (Even Outside of Dev)

Curiosity shouldn’t just stay within the tech realm. Sometimes the best ideas come from outside our daily tasks. Explore DevOps practices, grasp design principles, or delve into product management. Even if you focus on frontend work, learning about backend architecture or cloud infrastructure can be enlightening.

Learning across different fields not only makes us better developers; it helps us become more well-rounded thinkers. The broader our perspectives, the more connections we can make. So don’t hesitate to investigate other areas; you might discover your next big idea.

Balancing Trends with Core Knowledge

It’s easy to get caught up in the excitement of the latest and greatest, but it’s also essential to revisit and strengthen the basics. Staying curious doesn’t mean chasing every trend; it’s about building a solid foundation while keeping an eye on new developments.

When you have a firm grasp of the fundamentals, experimenting with new tools or frameworks becomes an exciting endeavor instead of an overwhelming one. You understand the core principles, allowing you to approach new things with curiosity rather than pressure.

Conclusion

The Fun is in the Journey!

Ultimately, learning isn’t just a means to stay current; it’s what makes this field so thrilling. There’s always something new to explore, something to tweak, and something to understand better. It’s about keeping things fresh, finding joy in small discoveries, and remembering that the journey itself is what matters.

So the next time you’re working with a new tool or trying out a fresh approach, remind yourself: you’re not doing this to check off a box. You’re doing it because this journey, with all its twists and turns, transforms development from just a job into a craft we enjoy. Keep learning, keep experimenting, and most importantly, keep having fun.

When you think about Scrum, you likely picture sprints, stand-ups, and retrospectives. But there’s one part of the Scrum process that doesn’t get enough credit: refinement. For many teams, refinement is just a recurring meeting on the calendar to clarify tasks or groom the backlog. It often feels like a checkbox item, something to get through before moving on. But here’s the truth: for developers, refinement is our secret weapon.

Why? Because refinement helps us stay ahead of the game. It’s our chance to identify dependencies, clarify requirements, and ask the questions that will save us trouble later. When done correctly, refinement reduces surprises and last-minute issues, setting us up for smoother sprints. Let’s explore why refinement deserves more attention and how it can make our lives as developers easier.

The Developer’s Perspective on Refinement

As developers, we’ve all been there. You’re halfway through a sprint, working on a task, and suddenly boom! An unexpected requirement or hidden dependency disrupts everything. A task you thought was simple suddenly becomes complicated. This is where refinement can be lifesaving.

Refinement gives us predictability. It’s our chance to understand what’s coming, see potential blockers, and know exactly what we’re signing up for. It also lets us take ownership of our work before the sprint even begins. When tasks are refined, everyone is aligned, and the sprint is more likely to run smoothly.

Real-World Examples: How Refinement Solves Problems

To see exactly how valuable refinement can be, let’s look at a few scenarios many of us have faced. I’m talking about those times when you’re mid-sprint, stressed, and suddenly find out something important was missed. With refinement, these problems can be caught early, turning potential crises into smooth sailing.

Example 1: Preventing Scope Creep

Scenario: You’re halfway through implementing a new feature when your product owner mentions, “Oh, can we add this extra bit of functionality?” Suddenly, a simple task just doubled in size.

Traditional Approach: Without refinement, this last-minute change feels like a bombshell. You’re too far along to pull out, but you don’t have the time or resources for the shift without derailing the sprint. Panic sets in, the deadline is threatened, and everyone feels stressed.

With Refinement: During backlog refinement, this feature is carefully discussed and refined. The team clarifies what’s expected, asks questions, and considers all angles, including potential additions or future changes. The product owner might mention the “extra bit” as a “nice-to-have,” allowing you to assess the scope accurately before committing. The result? No surprises mid-sprint; just a well-planned feature you’re ready to tackle.

Example 2: Identifying Dependencies Early

Scenario: Your task requires data from another team’s API. You’re ready to start coding, but the API isn’t prepared yet. Now you’re blocked, waiting for their team to finish before you can move on.

Traditional Approach: Without refinement, this situation doesn’t come up until it’s too late. You’re set to code, but you can’t proceed without that API, and there’s no backup plan. Your productivity stalls, and the entire sprint is now at risk.

With Refinement: During refinement, this dependency is identified immediately. You reach out to the other team in advance to confirm the API delivery timeline or plan a workaround. If there’s a delay, you can rearrange tasks to keep making progress. The sprint continues smoothly, with minimal delays and fewer blockers.

Example 3: Eliminating Ambiguities to Avoid Rework

Scenario: You’re implementing a user interface change, then halfway through, it becomes clear that the requirement was vague. The stakeholders now want something slightly different, necessitating a significant shift in what has already been built.

Traditional Approach: Without refinement, you’re knee-deep in the work before anyone realizes there’s a misunderstanding. The requirements were too vague, but there was no chance to clarify. Now, you’re stuck reworking the code, using time that could’ve been spent elsewhere.

With Refinement: In the refinement session, you ask questions about the new UI, such as “Does this include feature X? Do you want interaction Y?” By clarifying the details beforehand, you and the stakeholders share the same understanding from the outset. The task is straightforward, you’re focused, and rework is minimal or avoided entirely.

Why Skipping Refinement Can Haunt You

So what happens when we don’t prioritize refinement? We’ve all seen it go wrong:

• Last-Minute Scope Bombs: You’re mid-sprint and realize a critical requirement was missed. Now you’re scrambling to fit it in, and it’s consuming time you hadn’t planned for.

• Dependency Landmines: Without refinement, tasks with external dependencies can hit blockers just when you’re in the thick of things, forcing you to wait on another team or service.

• Developer Frustration: Working on tasks with unclear requirements or unknown blockers can lead to burnout. Refinement is our opportunity to address these issues before they arise.

These problems usually arise when we’re already mid-sprint and under pressure. This is why, as developers, we need to prioritize refinement, not just for the process, but for our own well-being.

Using Refinement as a Tool for Success

Here’s how we can view refinement as a developer toolkit to avoid mid-sprint headaches:

• Spot Dependencies Early: Part of refinement involves identifying who or what we’ll need to complete a task. Is there a service dependency? Do we need to coordinate a database change? It’s best to pinpoint these issues upfront.

• Catch Potential Problems: The earlier we identify tricky aspects of a story, the better. Refinement allows us to voice concerns and bring up edge cases, so we don’t get blindsided later.

• Clarify Requirements: Refinement is the ideal time to examine any vague requirements and clarify them, thereby preventing future blockers.

Refinement isn’t just a routine meeting. It’s where we make sure we’re ready for what’s ahead, turning uncertainties into clear steps forward. Think of it as a chance to prepare for a journey: the more familiar we are with the route, the fewer surprise detours we’ll encounter.

A 3-Step Approach to Streamlined, Effective Refinement

Over time, I’ve found that one of the most efficient ways to approach refinement is with a simple, 3-step framework. This process has worked well for me, keeping the team engaged and making the sessions much more productive. Here’s how it works:

1. Divide and Conquer: Start by assigning specific tasks to individual team members to read through and understand. This way, each person takes ownership of particular stories, rather than the whole team getting bogged down in every detail. If a task covers both frontend and backend, it’s best to pair up specialists (UI and backend developers) for a full-stack task. Their job is to dive deep and prepare to share their findings with the team.

2. Analyze and Document: Each “owner” or pair thoroughly reviews the task, discussing dependencies, identifying potential blockers, and listing resources they might need. They should document everything: to-dos, helpful links, dependencies, and any issues they foresee. This pre-work is crucial. It means the rest of the team doesn’t have to start from scratch in the refinement session.

3. Present Findings in the Refinement Session: Now it’s time for the refinement meeting. The task owners present their findings to the team, summarizing key points so that everyone understands the task without needing to conduct a deep dive themselves. This is when other team members can jump in, add insights, or raise flags they notice. It keeps the session focused since the “heavy lifting” has already been done, allowing everyone to focus on filling in gaps or discussing solutions.

This 3-step approach has proven to be a game-changer for me. Rather than dragging the entire team through every detail, it keeps things streamlined and efficient. It’s less draining than going line by line, keeps everyone engaged, and ensures that the team gains real value.

Wrapping It Up

Refinement as a Developer’s Superpower!

Refinement isn’t just a Scrum ritual; it’s a superpower for developers. It’s our chance to take control, turn uncertainty into clarity, and make sprint life much easier. When we treat refinement as a strategic tool, we’re setting ourselves and the entire team up for success.

So, next time a refinement session comes up, think of it as a tool in your kit. Jump in, ask questions, and use it to shape your work before it shapes you. A refined backlog is a developer’s best friend. Let’s make the most of it.

This isn’t just about moving code from one framework to another. It’s about leveraging a moment of change to future-proof the product, enhance user experiences, and establish systems that are scalable and easy to maintain over time. Missing this opportunity would be a waste of a chance to build a better product for both our users and our development team.

1. A Technology Shift is NOT Just a Simple Move

It’s easy to view a migration as a simple task: take what we have, move it over, and continue. However, if we think that way, we’ll miss a significant opportunity to improve our product.

Migrating isn’t simply copying and pasting existing code. Each technology offers its own benefits, and if we don’t take advantage of them, we’ll trap ourselves in outdated ways. Think of it like moving to a new house. You wouldn’t just pack up all the clutter and inefficiencies from your old home; you’d use the move to reorganize and improve your living space.

A successful migration lets us:

• Rethink how our architecture works, applying best practices we’ve learned over the years.

• Remove inefficiencies that have developed in our legacy code.

• Prepare for future growth by designing a system that can adapt and expand as new demands arise.

A “lift and shift” approach keeps old problems alive. By treating this as a chance to rethink and redesign, we can ensure our product doesn’t just survive this transition; it thrives beyond it.

2. The Perfect Moment to Tackle Technical Debt

Technical debt is a reality for any long-term product development effort. Over time, shortcuts are taken, code becomes messy, and workarounds accumulate. These decisions may have been necessary at the time, but now they create obstacles for future development.

Migrating to new technology is the best time to address this debt. Instead of carrying it over to a new platform, we can wipe the slate clean and build a more efficient foundation.

By using this time to refactor:

• Development becomes faster. Clean, well-structured code is easier to maintain and extend, resulting in fewer bugs and shorter development cycles.

• Scaling becomes smoother. Tackling technical debt now means we’ll face fewer bottlenecks as we grow, making it easier to manage increased user loads or add new features without disrupting existing systems.

This is our opportunity to get it right. We shouldn’t waste this moment by bringing legacy issues along. Cleaning up now will save significant time and resources in the years ahead.

3. An Opportunity to Greatly Improve User Experience (UX)

Changing technology is also an ideal time to review and enhance our product’s user experience (UX). Today’s users expect seamless, fast, and intuitive interactions, and technology shifts give us the chance to rethink how users engage with the product.

Why is this so essential? User experience impacts business results. Better UX leads to:

• Higher user satisfaction directly affects retention and conversion rates.

• Fewer support requests, since users can navigate the product without confusion or frustration.

• Quicker onboarding, as intuitive design helps new users get up to speed faster.

During this migration, we have the chance to:

• Streamline user journeys by eliminating unnecessary steps, making interactions smoother, and enabling users to achieve their goals more efficiently.

• Optimize performance. Better performance means a faster, smoother experience for users. Speed matters; every second saved decreases drop-offs and boosts engagement.

• Modernize the interface. Now is the time to apply modern UX principles, making our product not only functional but enjoyable to use.

This shift is not just a technical necessity; it’s an opportunity to deliver a better product for users and ultimately enhance business results.

4. Building a Strong Foundation for Innovation

A technology migration isn’t just about solving today’s issues; it’s about preparing for the future. Modernizing the system now means a more flexible, modular, and scalable foundation for innovation.

• Modularity: By creating smaller, independent components, we make it easier to evolve parts of the system separately. This prevents new features or changes from disrupting the entire product.

• Scalability: The demands of today won’t be the same tomorrow. By modernizing now, we prepare the system to grow with user needs, whether that involves handling more data, more users, or more complexity.

• Flexibility: A cleaner architecture allows us to adjust quickly to future technology changes. Whether integrating AI-driven features, adapting to new devices, or connecting with emerging technologies, a flexible system is crucial.

By making the right choices today, we create an environment that facilitates the implementation of future innovations, resulting in faster time-to-market for new features and a competitive edge in the industry.

5. Managing Expectations: This Takes Time, But It’s Important

We must recognize that a careful migration won’t happen overnight. Rushing the process risks overlooking the valuable opportunities mentioned earlier. Doing it properly takes time, but it’s time well invested.

By carefully managing the migration process:

• We prevent new problems that might arise from hasty transitions.

• We ensure long-term stability. A well-planned migration reduces the risk of costly mistakes later, sparing us from having to redo work.

• We stay aligned with strategic goals. This isn’t just a technical shift; it’s a business transformation. The result will be a stronger, more resilient product that meets both technical and business goals.

Rushing through these steps would miss an opportunity to build something truly extraordinary.

Conclusion

Take This Chance! This Migration is an Opportunity to Build Better

A technology shift isn’t just a task on a checklist; it’s a chance to build better. This migration enables us to rethink our approach, reorganize for optimal performance and maintainability, and enhance the product for both developers and users.

By using this migration to eliminate technical debt, improve the user experience, and future-proof the product, we are investing in the long-term success of both the application and the business.

This isn’t only a technical project; it’s a strategic move that will yield benefits in speed, scalability, and usability. Let’s not waste the chance to create something better, both today and in the future.

As a developer without a UX designer, you might think UX is beyond your reach. The good news is, you don’t need a whole UX team to make your products more user-friendly. With the right tools and approach, you can easily incorporate UX principles into your workflow and significantly enhance the final product.

Here are five practical steps to enhance UX without needing a dedicated designer.

1. Start with What’s Already Out There: Use Existing Patterns

Before diving into design work, look at what’s already working. If your team doesn’t have a formal design system, that’s fine! You can still use existing patterns to maintain consistency and user-friendliness.

Here’s how:

• Leverage established design systems like Google’s Material Design or Apple’s Human Interface Guidelines. These systems offer pre-built patterns that are widely used and easy to implement.

• Check your company’s past work: Even without an official design system, there’s likely a history of interfaces in your company. Use those to maintain consistency.

• Pro Tip: Consistency is helpful. Sticking to familiar patterns saves time and creates a smoother experience for users.

2. Map Out User Flows with Figma

After identifying the design patterns you want to follow, map out how users will interact with your product. You don’t need a fancy UX background; just a little empathy and a tool like Figma.

Steps:

• Use Figma to create simple wireframes. They don’t have to be perfect; they are just for visualizing the flow.

• Add annotations in Figma to explain each step of the process. It’s like leaving notes for yourself or anyone else involved in the project.

• Include screenshots from existing products or websites to highlight interactions you want to replicate. This helps when communicating ideas with stakeholders.

The key is to ensure the flow makes sense from the user’s perspective. Ask yourself: Is it clear what to do next? Are the necessary actions easily accessible?

3. Collaborate and Gather Feedback in Confluence

Once your wireframes and user flows are laid out, bring the rest of the team in. Confluence is an excellent tool for this. It helps document everything and collect feedback in one place.

Here’s how to use Confluence for collaboration:

• Embed your Figma designs into a Confluence page so everyone on your team can view them.

• Add clear descriptions and explanations of the user flow and key interactions to ensure a seamless experience. Make it easy for stakeholders to follow along, even if they aren’t designers.

• Use comments: Encourage your team and stakeholders to leave feedback directly in Confluence. This helps keep track of changes and ideas all in one place.

By combining Figma and Confluence, you create a straightforward process that allows everyone to stay in sync, even if they aren’t using the design tools.

4. Iterate Quickly with Early Feedback

One of the best parts of using tools like Figma is how quickly you can refine designs. Don’t wait until everything is built to get feedback. Get input early and often from your team and stakeholders.

Quick tips:

• Share your Figma mockups early to get input before coding begins.

• Use the feedback you collect in Confluence to adjust the mockups quickly. This way, you can ensure the design aligns with business goals before serious development starts.

• If possible, show the design to users or potential users. Even casual feedback from colleagues can help identify usability issues early.

This feedback loop saves you from having to rework code later, which can be time-consuming and frustrating. Quick adjustments in Figma are much faster than a complete development overhaul.

5. Use UX Decision Records to Build a Knowledge Base

Throughout this process, you’ll make many choices about how things should work and look. Don’t let those critical decisions slip away! Creating UX Decision Records (UXDRs) is a straightforward way to track key design choices.

What to include in a UXDR:

• The Problem: Describe the issue or need that led to the UX decision.

• The Solution: Detail the new flow, pattern, or design that was chosen.

• Feedback & Approvals: Capture input from stakeholders and note who approved the design.

• Guidelines for Future Use: If you create a reusable pattern (such as handling bulk actions), include instructions on how to use it in future projects.

Keeping these decision records organized in Confluence or another knowledge base will make future projects easier to manage. You won’t have to start from scratch every time a similar UX issue arises.

Wrapping It Up

Incorporating UX into your web development process doesn’t have to be complicated or require a dedicated UX designer. By utilizing existing patterns, mapping user flows in Figma, collaborating in Confluence, and maintaining feedback loops, you can create user-friendly products that align with business needs.

The main takeaway? Iterate quickly and communicate clearly. By involving stakeholders early and documenting your decisions, you can avoid last-minute changes and rework, while also providing a better user experience.

When you’re deep into web development, it’s easy to concentrate on the code. You have your frameworks, APIs, and deployment pipelines, all running smoothly. However, as many developers find out, if users can’t navigate your site easily or find it frustrating, no amount of clean code will make a difference. That’s where user experience (UX) comes in.

What Is UX?

User Experience (UX) is how users feel when interacting with your website or app. UX design aims to make products usable, enjoyable, and accessible. It involves understanding users’ needs and designing with empathy to create a product that feels intuitive and easy to navigate.

A website may work perfectly from a technical standpoint, but if users struggle to find key features or feel overwhelmed by confusing layouts, their experience suffers. The result? They leave, bounce rates increase, and conversions decline. Good UX design helps prevent these problems by guiding users through smooth interactions.

Who Is a UX/UI Designer?

You may have heard the terms’ UX designer’ and ‘UI designer’ mentioned. While they often work closely together, they have different roles:

• UX designers focus on the overall experience, researching user behavior, building user flows, and testing how the product should function.

• UI designers concentrate on the look and feel, choosing layouts, colors, fonts, buttons, and visual hierarchies to ensure the interface is both visually appealing and functional.

In many companies, these roles may overlap, and one person might handle both UX and UI design. The key is to ensure the product looks good and works well for the user.

What If There’s No UX Expert in Your Company?

Let’s face it - what if your company doesn’t have a dedicated UX designer? You might be in a small team, or perhaps the focus has always been on backend performance. Does that mean UX should be overlooked?

Definitely not! Here are some steps you can take even without a dedicated UX person:

• Look for a design system. Companies often have a design framework, even if it is informal. The design system could be a collection of reusable components or internal guidelines. Ask around - there’s likely something you can use. If not, consider established libraries like Material UI or Bootstrap. These libraries provide pre-made components that adhere to best practices, ensuring consistency.

• Gather inspiration. If you lack a design system, get creative. Platforms like Dribbble are great for finding design ideas. While not every idea will be a perfect fit, it’s a good way to explore modern design trends.

• Put yourself in the user’s position. Think about your product from a user’s view. Is it clear what they should do next? Are the key features easily accessible? A bit of user-focused thinking can make a significant difference.

• Use Figma to manage designs. Tools like Figma allow you to maintain designs effectively, even without a dedicated UX designer. Figma is free to use and lets you import libraries like Material UI or Bootstrap into your project. You can quickly create interfaces by selecting and customizing components, such as buttons, inputs, and navigation items, while adjusting properties like size, color, and spacing. It’s also a collaborative tool, letting multiple team members share feedback and make adjustments in real-time.

• Get feedback early. You don’t need extensive UX research to improve the user experience. Gather input from colleagues, stakeholders, or potential users to identify usability issues early on, before development starts.

UX doesn’t have to be complicated, and small changes can significantly enhance your project’s success.

Why UX Should Matter to Developers

As developers, it’s easy to see design as someone else’s responsibility. However, focusing on UX can actually make your life simpler. Here’s how:

• Fewer changes after development. One of the biggest hassles for developers is last-minute changes. By prioritizing UX early, you can avoid usability issues later in the process. It’s much easier to tweak designs before coding than to redo everything after deployment.

• Faster feedback from stakeholders. Good design streamlines feedback. Since making changes to mockups or wireframes is straightforward, you can get quick alignment from stakeholders and avoid major revisions. This keeps the development cycle smooth.

• Easier styling for developers. Not every developer enjoys adjusting CSS for perfect designs. A well-planned UI design provides a clear path, enabling developers to focus on implementation without getting bogged down in styling issues.

• Prevents mistakes. Good UX design requires you to think through the user’s journey in detail before development begins. This minimizes costly errors and confusing user flows that require later fixes.

How UX Helps Developers Collaborate More Efficiently

Good UX helps users and improves the entire development process. When designs are well thought out and thoroughly documented, developers have a clear understanding of what the final product should look like. This reduces confusion, speeds up development, and ensures the outcome meets everyone’s expectations.

A clear UX design acts as a guide, making it easier for developers and minimizing miscommunication between teams.

Conclusion

Ultimately, UX isn’t just for designers; it’s a vital component of web development that affects everyone, including developers. Even if your team lacks a UX expert, grasping basic UX principles can help you create better, more user-friendly products.

By focusing on the user, using tools like Figma, and utilizing design systems, you can build websites and applications that not only work well but are also enjoyable for users. So, next time you’re coding, remember: great code is essential, but great UX is what truly matters.