About
Experienced. Focused.
Ready to ship.
I'm a freelance software engineer with a Cand.Scient. in Computer Science from the University of Copenhagen. Since 2018 I've run Telos IT, delivering consulting and development work for Danish financial institutions.
My primary languages are C# and TypeScript, with F# for domains where correctness and expressiveness matter most. On the infrastructure side I work with AWS serverless functions, event-driven architectures, and managed services — keeping business logic decoupled from the platform via hexagonal architecture. A deep knowledge af the fundamentals of computer science and the languages ensure that the coded solutions are scalable and correct.
I believe that AI is a true force-multiplier and use it extensively in my daily work. I have always thought that the business and their needs should be front and center, and with AI it is, almost, possible for the business-users to define their own requirements and have AI code the solution. I can help the business define the requirements and steer the AI to make sure that the coded solution is correct and extensible.
My background spans Velliv, Forca A/S, Edlund A/S, Netcompany, and Danske Bank. The common thread: complex business domains, demanding correctness requirements, and code that has to keep working years later.
Get in touchWhere I fit in your process
I help businesses define, design, and deliver complex software — from requirements to running code. Specialising in C#, TypeScript, AWS, and clean hexagonal architecture that stays agnostic to cloud and storage. I can step in at any phase or stay for all of them. Scroll to explore each one.
Requirements
Every use case should map to a (part of a) real business process that someone actually performs. Each use cases should be a living markdown specs that sit in the repo alongside the code, so they change together with the system. The people closest to the business hold the most knowledge, and in the ideal world they would actually write the specs themselves. Often, however, the business person do not have the time or competencies to do this - my job is to turn that knowledge into use cases precise enough to build from.
- →Use cases front and center. Each one maps should map to a (part of a) business process
- →Specs written as markdown, colocated with the code and versioned in the same repo
- →Living documentation. Use cases change in the same commit as the code they describe
- →Stakeholder interviews/workshops to surface what the system actually needs to do
Design
AI makes it just as easy to generate a big ball of mud as a clean system, and just as fast. Choosing the right fundamentals early is what keeps speed from turning into spaghetti. Hexagonal architecture gives you a stable core that you protect and adapters that you can throw away.
- →Hexagonal (ports & adapters) and onion architecture. Pure core, side-effects at the edges
- →Cloud and storage agnostic by design
- →Domain-driven design to align code with business language
- →The right fundamentals chosen early, so AI-accelerated code stays maintainable
Development
Writing code has never been easier, so the hard part is deciding what to build. I spend the effort where it matters. I get to a running system fast, use it to discover the real requirements, and experiment cheaply before committing to a direction.
- →AI-accelerated delivery. The effort shifts from writing code to deciding what to build
- →Get to something running fast, then use it to discover what the business actually needs
- →Experiment cheaply at the edges and keep the core deliberate and clean
- →C# and TypeScript as primary languages, with F# where correctness matters most
- →AWS Lambda, API Gateway, SQS, SNS, DynamoDB, S3 via CDK infrastructure-as-code
Test
When AI writes much of the code, you can no longer trust it simply because you wrote it yourself. Verification matters more than before. This is where use cases close the loop. The same specs that defined what to build become the tests that prove the system does it.
- →Use cases drive the tests. Verify the system against what the business actually asked for
- →More generated code means more verification. Testing load goes up
- →Unit tests against the pure domain core. Fast, with no infrastructure needed
- →Integration tests at adapter boundaries to verify the wiring
- →Pensions domain experience means knowing the edge cases that matter
Deploy
Deployment should be boring. Infrastructure-as-code, automated pipelines, and cloud-agnostic design mean you can ship confidently and roll back safely.
- →AWS CDK for infrastructure-as-code — infra lives alongside the application code
- →GitHub Actions CI/CD pipelines — build, test, deploy on every push
- →Serverless-first on AWS reduces operational overhead
- →Same business logic can be deployed as Lambda, container, or on-premise
- →Environment parity — dev, staging and production configured consistently