Scroll

pikadev

The system gets designed, then the delivery gets run.

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

01

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.

02

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.

03

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. Talking it through is how the best version of the plan shows up.

Selected work In progress

Engagements led end to end.

Work

Every engagement, written up in full.

View all work →

Made it all the way down? Then this is where it starts.

Good architecture doesn't ship itself. Someone stays for the sprint planning and the release. That seat is where you'll find me.

Get in touch → How I think → Read the story →

Work

Engagements led end to end.

Tell me what you're building.

Get in touch →

Story

One company, four chapters.

The company

2019
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.
2020–2022
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.
2022–2026
Finding a path.

Content creation, experiments, prototypes. Trying things, taking them apart, building something better, until the right path showed itself.
2026
Relaunched.

Same company, new meaning, and the founder as its front. Solution architecture and delivery leadership, independently.

Why delivery, not just design.

How it started

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, the design only means something once a team can run it. Think of Dataverse, CRM, and the tangle of sales, marketing, service, and finance processes that all want to own the same customer record. 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 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.

Concepting is cheap. Shipping is the part that counts.

See the work → How I think →

Approach

How I think.

01

Architecture is a balance between scale and speed of delivery.

Over-engineering is a thing to avoid. Under-engineering is worse, and anyone who has lived through one knows it. I design architectures that drive the build: we invest in the foundations where it matters, and build fast around them where speed of delivery wins. Sometimes the cheapest design is one made to be rebuilt once the technology is mature enough.

02

A system without the business in it is a guess.

We can't know if a system serves the business unless people from the business test what we build while we build it. Designing it, finishing it and then handing it over is a disaster, and one I avoid.

03

Concept what can ship fast and change fast.

I often run the delivery as well as the architecture, so my concepts have to be buildable. Each one breaks into pieces we can ship quickly and adjust quickly, without laying a foundation that points the wrong way. When someone else already owns a role, I don't compete for it. I fill the gaps around it.

04

A backlog is clarity: now, later, and what ships.

Feature requests, wishes and actual needs all compete for the same sprint, and balancing them is where I'm strongest, whether I own the backlog or back up the person who does. Good backlog management makes three things clear: what we focus on right now, what stays in the backlog for later, and what goes into the sprint we ship.

The process

01

Map before you model

Data flows, team structure, and the real workflow get traced before a schema or a sprint gets planned.

02

Concept the thin slice

The smallest version that's actually useful goes in front of real users before the rest gets built.

03

Plan the release, not just the build

Sequencing, ownership, and rollout are architecture decisions, not an afterthought once the code compiles.

04

Leave a system, not a black box

Documentation and patterns the team can run without a single point of failure in the room.

See the work → 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.

Write to nasse@pikadev.fi

linkedin.com/in/joonashukka →

Turku, Finland

The system gets designed, then the delivery gets run.

I'm Nasse.

Solution architecture.

Delivery leadership.

Getting teams aligned.

Engagements led end to end.

Every engagement, written up in full.

Good architecture doesn't ship itself. Someone stays for the sprint planning and the release. That seat is where you'll find me.

Engagements led end to end.

Tell me what you're building.

One company, four chapters.

Founded.

Consulting.

Finding a path.

Relaunched.

Why delivery, not just design.

The details live in the work.

How I think.

Map before you model

Concept the thin slice

Plan the release, not just the build

Leave a system, not a black box

The details live in the work.

Tell me what you're building.