If you’re a Power Platform developer deep in flows, components, and custom connectors—you’re my kind of person. I’ve been there, troubleshooting infinite loops, reverse-engineering formulas, and pushing limits to deliver cool things on tight timelines.

But now, wearing the Solution Architect hat, I see things differently. Not because the code isn’t important (it is), but because there’s a whole layer of context that changes how you write it, and more importantly—why.

So here’s what I wish I knew earlier, and what I’d share with any developer ready to take their impact to the next level.

1. Your solution lives longer than your ticket.

That workaround you added to hit a deadline? It’s going to confuse someone (maybe future you) six months from now when the business changes a process or moves to a new region.

What I learned: Build with future maintainers in mind. Name everything well. Add comments. Write as if your solution will become the standard for the entire org—because it just might.

2. Don’t wait to ask “why.”

Before you jump into building, pause. Ask why the user wants this app. What problem are they really trying to solve? The real value isn’t just in delivering a button that does something—it’s in solving the right problem, the right way.

Architect tip: You’ll be amazed how many requests disappear or simplify once you dig into the root cause. That’s not laziness—it’s efficiency.

3. Reusability > Reinvention

If you’re copying a flow or app and tweaking for each team, there’s probably a better way. Think templates, child flows, or configurable components. It’s not just about elegance—it’s about scalability and governance.

What I do now: Build once, scale many. Start thinking in patterns and ecosystems, not projects.

4. The UI is part of the UX—but it’s not the whole story.

Beautiful screens don’t guarantee adoption. Sometimes it’s the slow flow, the unhelpful error, or the extra step users don’t understand that kill it.

Pro tip: Watch someone use your app. Don’t explain—just observe. Then go fix the things they hesitate on.

5. You are the first line of governance.

Yes, the COE toolkit helps, but developers are the ones closest to the data and process. That means you’re also closest to risks—like exposing sensitive info or creating dependencies that only work in dev.

What I ask myself now: If I hand this over to another team or tenant, will it break? If the answer is yes, it’s not ready yet.

6. Your work tells a story—make it a good one.

Solution documentation is part of the build. And no, it’s not optional. Think of it as legacy insurance—the thing that lets your solution live on, be upgraded, and integrated without you needing to be in the room.

7. You’re closer to the business than you think.

You’re not “just building.” You’re designing processes, changing behaviours, enabling outcomes. That’s leadership. Step into it. Ask questions, challenge ideas respectfully, and show that you’re thinking beyond just your component.

That’s how developers become architects.

If you’re a Power Platform dev who wants to go deeper—not just in code but in impact, context, and design thinking—you’re on the right track.

And when you’re ready to step into the architect seat, you’ll realise that the best architects never forget what it feels like to be a dev.

So keep learning, keep asking why, and keep building solutions you’re proud of.

From a fellow builder turned architect—see you at the next layer.