From architecture and technical leadership to the code itself. I
work with founders and teams when they need an experienced technical
lead who can make the decisions and then make them real.
The MVP has customers, and now it needs to behave like a
production system.
02
The product has outgrown its original architecture—but “rewrite
it” is not yet an answer.
03
Everyone owns a part of the system, but nobody owns the complete
technical picture.
04
The team is busy shipping while consequential structural decisions
keep being deferred.
05
You need CTO-level technical ownership before a permanent CTO is
the right hire.
06
A difficult existing system needs to be understood and stabilised
before anyone can change it safely.
What I do
One person. Four working modes.
An engagement can move between all four. The point is not to hand a
strategy to somebody else and disappear before the difficult part.
01
Fractional CTO & technical leadership
Technical ownership, architecture, sequencing, engineering
standards and team leadership—turning business requirements into
decisions engineers can act on.
02
Architecture & product engineering
Design systems around the actual product and its likely evolution.
Use the smallest architecture that is genuinely sufficient, then
add complexity only when it earns its keep.
03
System assessment, rescue & modernisation
Understand the system before changing it. Find the real
constraints, reliability and security risks, architectural debt
and expensive assumptions. Stabilise first; rewrite only where it
is justified.
04
Hands-on engineering
Prototype, build, review, diagnose and ship difficult or important
parts directly. Recommendations should survive contact with the
code and production behaviour.
Ways to work together
Start with the responsibility you need covered.
01
Focused technical assessment
A bounded review of a product, architecture or difficult system. I
inspect the evidence, identify the consequential risks and
decisions, and leave a practical sequence for what to do next.
02
Fractional CTO / ongoing technical ownership
Senior technical ownership without making a permanent CTO hire:
architecture, sequencing, standards, team support and decisions
that remain connected to delivery.
03
Architecture & hands-on product delivery
Design and build a product or major capability with direct senior
involvement from system shape through production. Useful when the
work needs ownership, not a hand-off.
Selected work
Responsibility, decisions, delivery and the operating reality.
Client and product details stay anonymous where the work is
confidential. The account below uses only facts that can be stated
publicly.
01 Anonymised · SaaS
From core architecture to an operating production platform.
Situation
A SaaS product needed technical ownership spanning product
decisions, architecture, implementation, AWS deployment and
operation after launch.
Úlfur’s responsibility
Design, build and technically lead the platform from core
architecture through product engineering, deployment and
ongoing operation.
Important decisions
Keep architecture, product engineering and AWS deployment
under one line of technical responsibility, so delivery and
operating behaviour could inform the decisions.
Delivered
A production SaaS platform and its AWS deployment.
Operational state
Deployed and in ongoing operation.
Broader professional experience includes SaaS, startups, banking,
insurance, travel/search, media/streaming and government.
How I work
A few principles that survive real systems.
01
Understand before prescribing.
Start with the business constraint, the product and the system as
it actually behaves—not the fashionable answer.
02
Let complexity earn its place.
Prefer the simplest architecture that is genuinely sufficient.
Complexity has a permanent operating cost.
03
Verify against production behaviour.
Architecture diagrams are hypotheses. Logs, failure modes and user
behaviour are evidence.
Current working set
Still close to the code.
The stack is not the service. It is how decisions get tested and
turned into working software.
APIs · Distributed systems · SaaS
· Infrastructure · Production operations
Python
since 2004
Django
since 2008
ÚK
About
I started as an engineer and never stopped being one.
I’m Úlfur Kristjánsson. My work began in software engineering and
widened over time: architecture, product decisions, infrastructure,
engineering teams and eventually whole technology organisations.
These days I work where those layers overlap. Sometimes that means
acting as a fractional CTO. Sometimes it means designing a system,
interrogating an existing one or spending the afternoon in the code
fixing the thing everybody thought required a rewrite.
I work independently and remotely with companies internationally.
Consulting services are provided through Robolobo OÜ.
