Morten, who?
Learning as I go. Building things, raising a family, trying to keep it simple. 🦒
I follow the rabbit hole until it becomes useful.
Some people specialize by staying in one lane. I seem to specialize by asking the same question in different rooms:
What is actually getting in the way?
I ask it in businesses, websites, products, football sessions, and ordinary family life. The setting changes. The work is familiar: notice what others have learned to ignore, find the real constraint, make the next move clearer, and build something sturdy enough for real life.
The titles change. The work underneath them does not.
Operator by necessity. Designer by curiosity. Builder by habit. Coach by conviction. Husband and father before any of it.
I build websites, products, systems, and learning environments that make the next action clearer. Most of what I know was learned while something real was on the line. I share what I am still learning because pretending to be finished would be dishonest—and fairly boring.
For services and professional fit, read the full profile.
Most of my education happened with consequences attached.
I did not arrive at design because I wanted to decorate the internet.
I arrived because businesses needed customers, customers needed clarity, teams needed systems, and most websites were making all three harder than necessary.
A customer was waiting. A crew needed an answer. Money was leaving the account. A page had to convert. A system had to survive the person who created it. A young player had to understand an idea well enough to make a decision without an adult shouting the answer. Home still needed me when the laptop closed.
That changes how you think.
You become less interested in what sounds impressive and more interested in what still works on a tired Tuesday.
You learn that a beautiful system nobody can use is not a good system. A clever explanation nobody understands is not clear. A marketing promise operations cannot fulfill is not marketing—it is debt. And a process that only works when everyone is focused, rested, and behaving perfectly does not work.
I build from that reality.
Sometimes the result is a website. Sometimes it is an operating system, a product, a training environment, a dashboard, a clearer offer, or one sentence that finally explains what everyone has been circling around.
The output changes. The instinct does not.
Find the actual problem. Remove what is getting in the way. Make the next action visible. Test it under real conditions. Keep what works. Admit what does not.
Different rooms. Same underlying work.
The disciplines look separate from the outside. From where I stand, they keep asking for the same things: attention, judgment, clarity, responsibility, and a useful next move.
Business operations
Where is friction costing trust, time, or money?
Make ownership, information, and the next action visible.
Websites
What must someone understand before they can act?
Build the structure, language, and interface around that decision.
Products
What has to work when the creator is not in the room?
Create useful defaults, repeatable paths, and recoverable mistakes.
Marketing
Can the operation fulfill the promise being made?
Fix the offer, proof, follow-through, and delivery before buying more attention.
Football
What does the player need to notice and decide?
Build an environment that teaches without stealing the decision.
Home
What is worth protecting from the work?
Time, presence, humor, and enough perspective to know when the screen can wait.
Swipe, scroll sideways, or turn the page.
Built for a tired Tuesday.
I do not trust systems that only work when everyone is having their best day.
Real systems have to survive interruptions, uncertainty, imperfect information, delayed replies, competing responsibilities, and people who are tired.
That is why I care about clear ownership, visible next actions, useful defaults, honest feedback, recoverable mistakes, and fewer things that depend on memory.
The real test is not the launch-day presentation. It is whether the thing still helps when the week gets messy and nobody has extra attention to spare.
A method, not a performance.
Notice before naming
Do not rush to solve the version of the problem someone happened to describe first.
Find the constraint
The visible issue is often a symptom of unclear ownership, missing information, conflicting incentives, or an unnecessary decision.
Make the invisible visible
Map the process. Write the sentence. Draw the flow. Put the decision where people can see it.
Build the smallest honest version
Not the smallest possible version—the smallest one that can fulfill the promise being made.
Test it in reality
A system is not proven by the presentation. It is proven by the person trying to use it.
Document what broke
Failure becomes useful when it changes the next version.
Improve without worshipping novelty
New is not automatically better. Familiar is not automatically outdated. The standard is whether the change helps.
For the delivery sequence, see how a project moves from idea to launch.
Beliefs are only interesting when they change the work.
Clarity before cleverness.
Originality is useful until it makes the next step harder to understand.
A person arriving at a page has their own task, context, and level of attention. A clever headline is not doing its job if it leaves them guessing what is offered, who it is for, or what happens after they click. Personality can stay; the meaning needs to arrive first.
Ask someone unfamiliar with the work to explain the offer and the next step in their own words. Listen for hesitation before explaining what you meant.
Useful beats impressive.
The person using the thing matters more than the person presenting it.
A polished screen can still make a simple job difficult. Useful work gives someone enough information to decide, a clear way to act, and a way back when something goes wrong. The standard is the experience of using it, including on an ordinary phone or a busy day.
Choose one real task, such as finding a service or sending an inquiry. Walk through the whole path, including the confirmation and the next action, before adding another visual flourish.
Proof before posture.
Show the work, the constraint, the result, and what still needs improvement.
Confidence is not evidence. A screenshot can show that something exists; it cannot, by itself, show that customers understand it or that it improved a business. Being precise about what was tested, what changed, and what is still unknown makes the work easier to trust and improve.
Pair a claim with something inspectable: the actual page, the test conditions, the decision behind a change, or a result with its date and limitations. Leave out numbers you cannot substantiate.
A promise creates operational debt.
Do not market something the business, product, or team cannot consistently deliver.
An offer is also a commitment for the people delivering it. If a page promises a quick reply, someone needs to own the inbox. If it promises a simple handoff, the information and process need to support that. More attention will not repair a promise the operation cannot keep.
Before publishing a promise, name its owner, the work it creates, and what happens when capacity is tight. Make the wording match what the team can actually deliver.
Systems should reduce dependence, not dignity.
Automation should remove unnecessary work without treating people like inconvenient parts of the process.
A good system helps people understand what is happening and where their judgment is needed. Automation and AI can organize repetitive work, but an output still needs a clear purpose and a responsible reviewer. Making a person work around a tool is not the same as helping them.
Define the task, the useful output, and the review step before automating it. Keep exceptions visible and give people a clear route to correct a mistake or reach a person.
Responsibility scales better than reach.
More attention is not automatically more value.
Getting more attention is only useful if the experience can support it. An unanswered inquiry or a confusing next step can undo the effort that brought someone there. Growth should include the capacity to respond, deliver, and learn from the people already trusting the work.
Trace one inquiry from arrival to follow-through. Check who owns each handoff and where it can stall before investing in bringing more people into that same path.
Children are not development metrics.
In coaching, progress matters, but confidence, curiosity, decision-making, and love of the game matter too.
A score or a training measure can describe part of a session. It cannot describe the whole child. Coaching also needs room for curiosity, confidence, mistakes, and the satisfaction of figuring something out. The aim is to help a player notice and choose, rather than rely on an adult supplying every answer.
Give the player a problem they can explore. Ask what they noticed, leave time for an answer, and look for a more thoughtful next decision as well as the final result.
Boring truths outlast viral advice.
The useful answer is often less exciting and more durable.
Clear language, working links, useful feedback, and reliable follow-through do not become less important when a new tool appears. They are easy to overlook because they are familiar. A new technique earns its place when it helps a real task, not simply because it is new.
Name the problem before choosing the tool. Try the smallest useful change, compare the experience, and keep the familiar approach when the new one adds effort without a clear benefit.
You cannot fly if you are not happy.
Ambition that removes all enjoyment eventually becomes another cage.
This is a reminder to examine the cost of ambition, not a promise that meaningful work always feels easy. Difficult days are part of building anything. But a way of working that leaves no room for family, curiosity, rest, or enjoyment deserves questioning too.
Look at what the current pace requires you to give up. Decide what needs protecting, what can wait, and what can become simpler without abandoning the work that matters.
The polished version is usually missing the useful parts.
I do not have a perfectly linear story.
I do not believe every lesson needs to become a framework.
I do not know everything before I begin.
I use modern tools, including AI, but the presence of a tool does not excuse weak judgment.
I have built things that worked, things that broke, and things that taught me more than they returned.
I would rather show the unfinished reasoning than manufacture certainty after the fact.
The reasoning lives in the Journal’s field guides. The evidence lives in the selected work.
A living page should admit that the work is still moving.
- Products, websites, and operating tools that turn complicated work into clearer decisions.
- Where AI removes real friction—and where it quietly removes judgment.
- Whether the next feature is actually more useful than a better sentence.
- Teaching more clearly, documenting sooner, listening earlier, and leaving enough room for the people I am building for.
Let’s work through it together.
I work directly with a small number of businesses, founders, and teams that need senior-level thinking and hands-on execution—without adding another layer of account management or hiring a full internal team.
Put me on the problem.
You bring the difficult, unfinished, or unnecessarily complicated thing.
I help identify the real constraint, clarify what should happen next, and work directly on the solution.
That may include product design, website design, brand systems, user experience, prototypes, practical AI integration, or the workflows connecting them.
An introduction first. We’ll agree the fit, scope, and timing before any work begins.
- PRODUCT DESIGN
- WEB DESIGN
- BRAND SYSTEMS
- UX + CONVERSION
- PROTOTYPING
- PRACTICAL AI INTEGRATION
- WORKFLOW DESIGN
Is this the right fit for you?
Limited availability. Best for established businesses, founders, and teams with a real problem, access to the necessary people and information, and the ability to act on the work.
Not unlimited requests. Not four disconnected projects at once. One important problem, moved forward properly.
This is an inquiry, not checkout. Final scope, timing, and terms are agreed before work begins. Fixed-scope website projects are a separate engagement model.
One question deeper.
Years ago, my email signature borrowed a famous invitation to leave the safe answer and follow the rabbit hole.
I retired the borrowed line, but not the instinct.
I still believe the useful answer is often one question deeper. I simply care more now about whether the answer helps someone, survives contact with reality, and leaves a little more room for curiosity.
You can’t fly if you’re not happy.
There’s more to explore.