Business and operational problems · Technology · AI
We solve the problems an organisation cannot get moving on its own.
Hard, ambiguous problems where business, operations and technology meet. The ones stuck between teams and systems. We go into how the work actually runs, test the assumptions that matter most, and carry the problem through to a working solution. Software and AI are tools, not the starting point.
The first conversation is free. A few sentences about the problem are enough.
01 · Does this sound familiar?
Before we talk about ourselves, see whether you recognise your own organisation here.
People move data between systems by hand. “Temporarily” — for the past three years.
An important process rests on what two people know. When they are away, it stops.
The problem cuts across several teams, so nobody owns it.
The system stopped keeping up with the process. The workarounds cost more than the system does.
Different systems hold different versions of the same fact. Nobody knows which one is true.
There are so many exceptions that an off-the-shelf solution will not cover them.
The business knows what outcome it wants. Nobody can turn that into a specification.
IT knows the systems but has no room to get deep into operations.
You have been analysing it for months. There is still no working proof.
If even one of these sounds like you, that is exactly the class of problem we take on. Too important to ignore. Too unusual, or too small, for a large transformation programme.
02 · What we do differently
We do not sell people or hours. We sell the journey from an unclear problem to measurable value.
We do not sell a team or billable hours.
We take responsibility for carrying the problem through to an outcome.
We do not start with technology.
We start with what has to change in the business or in operations.
We do not require a finished specification.
We need access to the real process and to the people who work in it.
We do not finish with a presentation.
We finish with a working solution whose effect can be measured.
We do not assume the answer will be an app or AI.
We get quickly to an experiment that shows what actually works.
03 · How we work
Six questions, in this order.
This is not a methodology to roll out. It is how we run every problem — from the first conversation to the day the solution works without us.
Outcome
What actually has to change in the business or in operations? Without that, we do not go further.
Reality
How the process really runs: the exceptions, the workarounds, the data and what people actually do.
Options
Which classes of solution make sense. An app and AI are only two of them.
Proof
The smallest experiment that settles the biggest unknown.
Value
Whether the solution really moves the outcome. We measure rather than assume.
Handover
How to make the solution run without a standing dependency on us.
04 · From conversation to value
Four stages. After each one, you decide whether we go on.
You do not have to buy the whole journey. Every stage ends with something worth having on its own, and with a decision about whether the next investment makes sense.
Problem framing
Problem FramingAn intensive look into the process, the data, the exceptions and the constraints. We look for causes, scale and the biggest unknowns. The output is not a hundred pages of analysis — it is a decision.
A map of how things really are, the cost of the problem, the solution options, and the experiment that will settle the biggest unknown.
Proof of value
Proof of ValueThe smallest thing that lets us test the key hypothesis in a real environment. Not a cheaper version of the product, but an answer to whether the idea works and delivers the change you expect.
A working slice of the process under real conditions, and a measured effect.
Production solution
ProductionIf the proof confirms the direction: build, integrations, security, monitoring, rollout, and getting the organisation ready to use the solution.
A solution running in production, with monitoring and a record of the decisions behind it.
Handover and scaling
TransferYour team takes the solution over; we help scale it into further areas, or jointly maintain one agreed component.
Your organisation standing on its own. No technological orphans.
We do not design vendor dependency. The solution has to work once we are gone.
05 · Why we move fast
We bring our own workshop, not just people.
We do not start a project from an empty repository and rebuild the infrastructure from scratch. We keep developing our own set of mechanisms that shorten the path from a problem to the first working solution. Add a small number of very experienced people and one problem at a time.
Proven architectural patterns and ready components
Our own ways of prototyping quickly
Methods for getting to know existing systems, code and documentation fast
Automation of the repetitive parts of development
Testing standards from day one
Observability built into the solution, not bolted on afterwards
Decisions documented alongside the code
AI as a standing part of how we work
06 · AI in practice
We use AI first and foremost in our own work. Only then in what we build for clients.
It changes the economics of a small team: we can learn a large existing system faster, build a prototype, test it and document the decisions. Without that, a handful of people could not take on problems of this size.
Learning the existing system
Reading documentation and code
Prototype
Development
Testing
Analysing data and exceptions
Migrations
Documenting decisions
The AI layer in how we work
Models, coding agents, our own tooling and standards for working with code
Want to change how software gets built in your own team the same way? We can help with that too.
Let us talk about itOne caveat
AI is not the goal. If a simple script, an integration or a change to the process solves the problem better, we will propose the simpler thing.
07 · Example problems
The kind of work that fits us.
Anonymised scenarios, not case studies. They are here to help you place your own problem.
Two systems, two versions of the truth. The team reconciles them by hand every day.
Information kept in sync between the systems, and one place that shows the actual state.
Your clients have their own systems and will not click around in yours. Someone retypes orders and statuses.
An integration that removes the manual process before it grows into a full-time job.
The standard process handles 90% of cases. The remaining 10% eats half the team's time.
Exception handling automated around what the exceptions actually look like.
Operational reality does not fit the model of the existing system. Workarounds keep multiplying.
A thin layer between the systems that gives operations a true picture of the process again.
There is an idea for using AI. Nobody knows whether it will work on your data.
A fast experiment on real data that gives you an answer before a budget exists.
A software team wants to work with AI but does not know where to start or how to measure it.
An experiment on a real project, a change to the workflow, and a measurement of the effect.
08 · Why ANSLAN
We started from a single observation.
There is a large class of valuable problems that organisations cannot handle with the operating model they already have. Big programmes are too heavy. Roadmaps have higher priorities. A software house needs a specification. Consulting often ends with a recommendation.
ANSLAN steps in between those models and takes responsibility for the journey from a problem to value that works.
Founder
Sławek Łukjanow
He has been programming since he was eight. Over more than twenty years he worked as a developer, architect, CTO and co-owner of a technology company, and later as a product owner, solution architect and technical programme lead in large operational organisations. He has built systems for manufacturing, construction, medicine and logistics.
He knows operations from the side of the people who work in them, and systems from the side of the code. At ANSLAN he is responsible for how we work, for the architecture, and for the quality of direction on every mission.
09 · Contact
Book a consultation.
The first conversation is free and has one purpose: to understand the problem and judge honestly whether we can add value. If we cannot, we will say so plainly. You do not need to prepare a specification or a presentation.