60.45°N · 22.27°E — Turku, FI · Solution architecture & delivery leadership
The system gets designed, then the delivery gets run.
Technical workstreams get planned and led. Architecture gets shaped with the team, not handed down to it. Sprints get run, releases get shipped — I'm the one who stays for all of it.
Who's behind it
i'm nasse.
I started pikadev as its founder — these days I work as a solution architect and delivery lead: I design the system, then stay to run the delivery.
My childhood career plan was to become a LEGO engineer. I always enjoyed building something, showing it, taking it apart, building something better. The journey was always the point, not just the finished model.
The medium changed; the pattern didn't. These days the builds are technical workstreams, and the teams building them get a plan, a lead, or both.
get in touch →What I do
Solution architecture.
People don't need systems to do things — they need things done. Business keeps running without interruptions, and new ideas get room to be tested; the architecture has to hold both, for everyone in the loop — stakeholders, operations, and the team building it. My part is caring about the things nobody else in the room should have to care about: the system landscape, scale, security, whether things stay easy to develop, maintain, and extend. Everyone else gets to care about results.
Delivery leadership.
Backlogs, sprint plans, releases. The work that decides whether a good design becomes a shipped system — done well, it's barely visible; done badly, it's all anyone talks about.
Getting teams aligned.
A shared goal and a shared direction, understood the same way by everyone the delivery touches — operations, development, design, stakeholders. Alignment like that is built on trust: people have to feel safe questioning any idea, mine included. I lead with strong opinions about where things should go, and I invite the challenge — dialogue is how the best version of the plan surfaces.
The company
Founded.
A SaaS product built to fix a hiring problem I'd hit myself. Won a demo day, overengineered the product, sold the commercial operations in 2020. Kept the company — and the lessons.
Consulting.
Product and business development for another SaaS product — the company was more than just me by then. It taught us what clients actually demand, and how to do things right.
Finding a path.
Content creation, experiments, prototypes. Trying things, taking them apart, building something better — until the right path showed itself.
Relaunched.
Same company, new meaning — and the founder as its front. Solution architecture and delivery leadership, independently.
Good architecture doesn't ship itself. Someone stays for the sprint planning and the release — that seat is where you'll find me.
work
Engagements led end to end.
story
Why delivery, not just design.
I didn't start out wanting to be an architect. I started out wanting to be the person who could tell you why the thing everyone was building was about to fall over — and then actually stop it from happening.
Solution architecture, done properly, isn't a diagram exercise. In the Microsoft ecosystem especially — Dataverse, CRM, the tangle of sales, marketing, service, and finance processes that all want to own the same customer record — the design only means something once a team can run it. So somewhere along the way, delivery stopped being someone else's job to hand my architecture to. I started staying for the sprint planning, the backlog grooming, the release. Not because nobody else could do it, but because architecture and delivery are the same conversation, just at different zoom levels.
I've joined teams as the outside advisor called in to unstick one decision, and I've joined as the person leading three technical workstreams at once because that's what the org needed that quarter. Both are the same job: find the path that gets people aligned on what to build next, and make it concrete enough that Monday morning has a plan.
What I'm adaptable about is the situation — a migration, an integration, a team standing up a new process, a roadmap that needs to survive contact with three departments' competing priorities. What I'm not flexible about is finishing what gets started. Concepting is cheap. Shipping is the part that counts.
approach
How I think.
A plan nobody can execute isn't architecture — it's a slide.
The org chart is part of the system. Design it or inherit someone else's.
Concept fast enough to be wrong cheaply, and often.
A backlog is a promise. Groom it like one.
Map before you model
Data flows, team structure, and the real workflow get traced before a schema or a sprint gets planned.
Concept the thin slice
The smallest version that's actually useful goes in front of real users before the rest gets built.
Plan the release, not just the build
Sequencing, ownership, and rollout are architecture decisions — not an afterthought once the code compiles.
Leave a system, not a black box
Documentation and patterns the team can run without a single point of failure in the room.
This way of thinking started somewhere specific — read the story.
contact
Tell me what you're building.
A technical workstream that needs a lead, an architecture decision that needs a second opinion, a team that needs someone to run the release — start here.
nasse@pikadev.fi