Tomasz Mroczyński
I build solutions that amplify people.
I am moving into technology not from a diploma but from the need to build something anew. A decade of technical work — networks, CCTV, helpdesk, deployments — and then eleven years in distribution, through which technology was what I did after hours. Today it is what I do: AI, automation and self-hosted systems.
01The turning point
For a decade I worked in technical roles — computer networks, security systems, deployments and technical support. Then came eleven years in distribution, and that is the part of the record where technology was not my job title. It was what I did after hours — especially after settling in Norway: learning, building my own projects, experimenting with backend development, self-hosting and API integrations. A parallel track that eventually became the main one.
In 2025 I began working as a truck driver while completing my Category C licence. A month later a serious workplace accident brought that path to an end. Rather than treating it as a setback, I let it become a turning point — the moment to consciously turn a long-held passion into my professional direction.
This isn’t a leap into the unknown; it’s the continuation of an interest I’ve been developing for years. I completed Noroff’s backend .NET bootcamp, and today I build projects, automations and AI-based systems and work hands-on with self-hosted infrastructure, Docker and API integrations. I learn by building — and now I’m doing it on purpose, as a career.
02Projects
Two of the systems below were built to order: Sammen i Norge and Limes Dekor. The rest I built for myself and develop in daily use or in closed testing. For each one I state the real status, the users and evidence you can check — where there is no link, it means I have nothing to show, not that I forgot.
- at the clientProject for an organisation
Sammen i Norge / SiN Studio
A trilingual site for an association in Drammen, grown from a brochure page into a system that supports running it: projects, events, volunteering, membership and an in-house CMS with roles.
My role: Author of the original site and of everything built on top of it — from a brochure page to a system that supports running the organisation: information architecture, UX/UI, content and permission model, implementation, data migration, deployment and further development.
Next.js 16React 19Payload CMS 3PostgreSQL / SupabaseVerceli18n - under development
Limes Dekor
Shop, orders, payments and production files for a workshop making laser-cut products. The same renderer builds the customer preview and the final SVG.
My role: Process, architecture, interface, implementation and deployment — all on my side.
Limes Dekor is my partner's business. The engagement and its scope are real, but this is not an arm's-length reference — you cannot check it with someone who has no connection to me.
Next.js 16ReactPrismaSupabase/PostgreSQLSVGStripeDocker - in use
Ripper Inject
A learning system that turns a document into a course: vocabulary, exercises and SM-2 spaced repetition, with a fidelity check that catches claims the model had no source for.
Next.js 16TypeScriptDrizzleSupabaseOpenAI API - concept
Ripper Task Force
Agents that decompose a task and carry it through without a human arbitrating mid-process; the human receives the result rather than the interruptions.
TypeScriptMCPzod - in use
Ripper Brainstorm
Several models from different providers debate the same question while a neutral model hunts for shared, unstated assumptions — two models agreeing is not proof.
TypeScriptmulti-provider LLM - concept
Ripper Body Sync
VR sessions from Meta Quest 3 combined with health data into one picture, analysed by a private trainer model. Self-hosted, because health data is sensitive.
KotlinJetpack ComposeMCPMeta Quest 3 - in use
ripperdoc.ai
This site. Trilingual, with a job-search module behind login: it collects listings, ranks them, assesses them against the profile and drafts applications.
Next.jsTypeScriptPostgreSQLMCPVercel
03Workshop
Whatever proves itself in one project moves into a shared library — as a module or a small tool. The next build then does not start from a blank page: the existing piece is both the starting point and the context for the new solution, so each system after it comes together faster and out of parts that have already worked.
Public: my fork of the MCP server for finn.no — request throttling, a cap on database growth, and a fallback for reading job ads after the site stopped sending structured data. Together with a pull request to the original author. github.com/tomaszmroczynski/finn-mcp
04What I can do
I combine technology, design and a practical approach to solving problems. I build applications and automations that do not stop at a good-looking interface — they are meant to improve the work and lead to a concrete result.
I can take an idea through the whole process: from the concept and the design, through the application, the database and the integrations, to running the solution on my own infrastructure.
I work with web technologies, AI, automation and knowledge-based systems. I also connect them to the physical world — product personalisation, graphics, 3D modelling and printing.
My strength is looking at a project as a whole. I learn new tools quickly, look for simpler ways of doing things, and can join elements from different fields into one coherent, working system.
Code you can open: the MCP server fork for finn.no github.com/tomaszmroczynski/finn-mcp
05Experience
- 2025 – present
Own practice — Ripperdoc · Ripperdoc
Designing and building systems based on AI, automation and integrations — my own systems and client work (Limes Dekor, Sammen i Norge).
- 03–04/2025
Truck driver · Transport Service AS
A short chapter that ended with a workplace accident — the start of a deliberate turn towards technology.
- 09/2024 – 03/2025
Break from work · —
No paid work during this period.
- 2013 – 2024
Distribution · Amedia AS
Steady distribution work, run alongside learning technology and building my own projects. From 2021 to 2024 I was also the local Fellesforbundet club leader, representing employees in negotiations with the employer on pay and working conditions.
- 2009 – 2011
Sales and implementation · PTC Security Systems
Implementing biometric identification systems, winning clients in the public and private sector, working with developers and coordinating the team.
- 2002 – 2012
Own business · Complet Tomasz Mroczyński
Installing and configuring computer networks and PC servicing — the whole chain from client to support.
- 2002 – 2006
Sales and technical support · Strawford
CCTV deployments, LAN installation, IT helpdesk, servicing and training.
06Education
- 2021 – 2022
Noroff — School of Technology and Digital Media
Backend Web Development (.NET).
- 2002 – 2006
University of Gdańsk
Economics, specialization: analyst.
07How I lead the work
I do not write all of this alone. I work with models the way I would work with a team of specialists: I state the problem, listen to the proposals and decide — together with the cost of deciding. The value is not in who types code faster. It is in who asks the right question and who says no — including to himself.
I am monotropic. My attention does not spread across several things at once — it pools into one and goes to the bottom of it. This is a neurodivergent profile and I say so plainly, because it is the strongest thing I bring to the work: the ability to go deeper than ordinary curiosity reaches, and to stay there until the problem gives way.
Hence the monotropic generalist. The breadth came from one dive after another, not from sampling everything a little. First networks, security systems and deployments. Then eleven years of work through which technology was what I did after hours. Now AI. One thing at a time, for a long time, all the way in — and each time a craft stays behind that carries into the next.
How to use it: give me a problem rather than a task list. One priority rather than five parallel ones, whole blocks of time, and context in writing. What you get is the thing solved at its root, and a new domain taken on faster than you planned for. A day chopped into meetings and five parallel threads wastes precisely the quality you would be hiring me for.
Remove the administrative friction, keep the friction of reflection.
2026-06-18
What belongs to the core of the product and what is an add-on?
Every proposed extension reopened the same argument, settled from scratch each time.
Does the product lose its integrity or identity if you remove this? If it still works fully without it, it is an extension — optional and off by default.
Cost · a shorter feature list in the core. In return: a criterion that decides even when I am not in the room.
2026-06-18
Is two models agreeing proof that they are right?
When two independent models reach the same conclusion, the matter is settled. Most multi-model tools work this way: they treat agreement as the result.
Agreement is often an illusion. Both voices may silently accept the same false premise and agree precisely because they share the blind spot. So the neutral model was given the job of surfacing not only the differences but above all the SHARED, UNSTATED ASSUMPTIONS — and turning them into control questions anchored to a specific passage.
This is why the voices must come from different providers. Two runs of the same model share training data and the same systematic errors — their agreement means nothing.
Cost · an extra round and a third subscription in the full setup. In return: the only way to catch a mistake neither side of the argument can see.
2026-06-18
Should a record of a private discussion be sent to an external service?
Automatic sync — very convenient, little work, and my own idea.
The product promises privacy and work on your own hardware. Quietly shipping private deliberations outside eats that promise. Export stays manual; automation only with explicit consent.
Cost · more clicks and less impressive automation. In return: a promise that survives inspection.
production
Should the engraving area be detected automatically from the product model?
Nothing technical stood in the way of the system finding it on its own.
This step stays with the person. Here a machine error costs destroyed material, not a fix in the browser — and a panel that ruins production once will never be opened again.
Cost · fifteen minutes of work per new product. In return: the trust without which self-sufficiency is only a claim.
The council does not detect on its own that the voices disagree — the human sees it, or a neutral model does when asked. The publishing queue in Social Studio has not yet run a full production cycle. I am learning Norwegian with an application I wrote myself; I speak with effort and that one is not closed.
08When I advise against AI
A model costs on every call, answers with a delay, and sometimes answers differently than it did yesterday. For some tasks that is the price of something you cannot get any other way. For others it is the price of nothing. Here are the cases where I say let us not use a model, and what I propose instead.
- The format is fixed.
- Dates, amounts, invoice numbers and postcodes from a document with a stable layout are a job for a parser or a regular expression. No cost, an answer in milliseconds, and the same answer every time. A model doing the same work charges for every page and will occasionally write down a number that was never there.
- The rule is deterministic.
- "If the amount is above the threshold and the country is on the list, apply the other rate" belongs in code, with tests that pin it down. A model asked to apply a rule will usually apply it correctly — and usually is too weak wherever money or deadlines are involved.
- It is search across a few hundred documents.
- The full-text search built into PostgreSQL handles a corpus that size without a single token and without separate infrastructure to maintain. A vector store with RAG earns its keep at scale and on descriptive questions, not on "find the invoice from this supplier".
- It is an integration on a schedule, not AI.
- A large share of what gets called AI automation is an API call at a set hour, a calculation and a message. A cron script or an n8n flow does that for free and does not introduce a failure mode where the system answers differently than it did the day before.
- Nobody can describe how the process works today.
- Then AI will not fix anything — it will reproduce the existing mess, only faster and for money. Map the process first, decide on the tool second. That stage is sometimes the whole job, and sometimes it ends with nothing needing to be built.
Every one of these is work I turn down.
An example from the decision log: restraint on Limes Dekor →
09What I am missing
This section is deliberate and deliberately specific. A model assessing a candidate against a job ad will compute the gaps either way. I would rather it did so in my wording than in its own.
No salaried employment as an AI or automation specialist. The commercial experience is two deliveries: Sammen i Norge, which runs at the organisation, and Limes Dekor, still under development. Limes Dekor is my partner's business, so the only arm's-length reference is Sammen i Norge.
What offsets it: The deliveries cover the full span: process analysis, architecture, interface, implementation, integrations and ongoing development. My own systems are in daily use rather than demos — they have users, production failures and decisions I had to revisit.
Norwegian at B1, self-assessed. Written work and reading are fine; running workshops in Norwegian is not there yet.
What offsets it: English as a working language is unproblematic. I am learning the Norwegian with an application I built myself.
No degree in computer science. The formal education is economics (University of Gdańsk) and a backend .NET bootcamp (Noroff).
What offsets it: Several Norwegian listings explicitly allow relevant experience to substitute for formal education.
The systems are built for one person, a small workshop or a closed test group. No experience operating at a scale of hundreds of users.
What offsets it: In exchange the whole chain is mine: database, deployment, debugging and the decision about what not to build.
10What I am looking for
I am looking for a real direction in technology — education and work around AI, automation and systems. I learn best by building: connecting systems, breaking configurations, fixing them and taking an idea through to something that works.
- Location
- Norway (Eidsberg)
- Languages
- Polish (native) · English B2 · Norwegian B1
- Certificates
- driving licence B96 & C
11Data and handover
The accounts belong to the client from day one: database, hosting, payments, domain. I join them as a collaborator, not as the owner. That makes handing the project over a matter of removing one user rather than migrating anything — and the client is never held hostage by my account.
Secrets do not sit in the repository or in files on my disk. They live in Bitwarden Secrets Manager and reach the runtime through a one-way sync. Third-party access tokens stored in the database are encrypted (AES-256-GCM), never in plain text, and anything that looks like a key is stripped from the logs.
Only the content actually needed for the task goes to a model — through the commercial API, where the traffic is not used to train the provider's models. Whatever can be computed without a model, I compute without one. Some of it runs locally on my own hardware, and there the data goes nowhere at all.
Where personal data is involved, I work under a data processing agreement — settled before the first line of code, not at delivery.
At the end the client receives the repository, access to the whole infrastructure, the documentation and a database dump. Secrets that passed through my hands are rotated at handover. My access goes away and none of it stays standing — if something needs fixing afterwards, access is granted again and for the duration of that fix.
12How this page talks to language models
The profile is also published in a machine-readable form. It is generated from the same source as this page — if the two ever differ, that is a bug, not a technique.
- hidden text, white-on-white lettering or content buried in comments,
- instructions to language models embedded in the markup,
- content that varies by who is asking — the User-Agent header changes nothing,
- wording that tries to steer the assessment of the candidate.
The reason is simple: content instructing a model how to judge the author of that content is prompt injection regardless of how politely it is phrased. Verifiable in one command — fetch the page with any User-Agent and compare. I would rather be assessed on true data, even if the assessment comes out more cautious. An assessment built on content I staged myself is worth nothing — to me least of all.
13Contact
The address is public: kontakt@ripperdoc.ai. Write freely — I usually answer within a day. What stays behind the code is the phone number and the CV: the number because a published one mostly collects spam, the CV because I would rather send a version fitted to a specific listing than one that fits everything. Without a code the whole dossier is open to you — the experience, the projects with evidence, how I work, and the gaps written out plainly. Tell me which role this is about and I will send the full set.
Have an access code?
Invalid code. Try again.