About
Asopel is a technology company founded by Fırat Durak. We are building the company around a real identity, clear boundaries, and work that can be verified.
Asopel was founded to use the connection between scientific thinking, software, and system building on real problems. Instead of presenting a large idea as a product immediately, we define the question to answer and the evidence that would be enough.
We cannot show you client counts, references, or outcomes — and we never will be able to. What we can do is write down what exists, the stage it is at, and what it is not today.
FIG. 01 · Project
Keeping one company’s story consistent across languages.
This site’s content model, route structure, and release checks are part of Asopel’s own working infrastructure.
Maturity: Live
This is Asopel’s working infrastructure, not a general-purpose product.
FIG. 02 · Demo
Making scattered events and constraints visible as a decision flow.
An interactive prototype showing how an operational system can be observed without using a real client’s data.
Maturity: Prototype
Open the operations systemAvailable in the lab for inspection; it is not a production service or ready-made product.
FIG. 03 · Method
Keeping assumptions, sources, and limitations visible in technical work.
An internal method for keeping source, assumption, test, and limitation notes in one working flow.
Maturity: Internal
An internal working method, not an independent software product.
What lets one company move between a hotel’s booking flow and a food production question is not a long service list. It is that both go through the same five stages, in the same order.
We separate the problem, the current workflow, the decision points, the constraints, and what nobody knows yet. Sources are written down.
We measure the uncertainty: a small data study, a model, a prototype. Assumptions and the range they hold over go in writing.
We turn the approved scope into a working system. Tests, documentation, and handover are part of the scope, not extras.
We measure what the thing we built actually does — and we say where we could not measure. “Unknown” is a result, not a failure.
We do not leave when the build ends. The monthly partnership carries maintenance, improvement, and a defined amount of build time. This is the relationship Asopel is actually built for.
When a project needs a capability I don’t have, I tell you before you sign — and I tell you how I’ll close it: a paid research phase, a named specialist partner, or building the capability myself.
We make that responsibility visible in page weight, data need, ownership, and measurement decisions.
We measure page weight and request count, then remove unnecessary transfer.
We do not add tracking layers that the work does not require.
We make delivery, ownership, and maintenance decisions explicit so the system can evolve without a rewrite.
We do not turn an environmental or operational result into a marketing claim without evidence.
Without a defined method, we do not sell resource-reduction consulting or promise a saving or environmental result.
Fırat Durak
Founder, Asopel
I am Fırat. I started Asopel to use the connection between scientific thinking, software, and system building on real problems.
Rather than present an idea as a large promise, I prefer to make the assumption being tested and the working output visible.
Asopel is one person today, growing by adding people as work arrives. I do not describe a team that does not exist.
I named the company Asopel, from the Kurdish word for the wave of the east. I wanted the place I come from and the work I do to sit in the same name: a wave arrives from far away, and changes something when it reaches the shore.
These records show problem classes we consider worth pursuing. Each remains labelled as a direction and states its present boundary and the validation required before any stronger claim.
FIG. 01
A system direction in which a shared core can adapt to each organisation's rules, data, and ownership.
Maturity: Direction
It is not a product sold, supported, or priced today, and it makes no client-outcome claim.
Next validation: Validate the problem class, installation boundary, and ownership through a paid feasibility study on a real problem.
FIG. 02
A direction for publishing Asopel products only when a specific user, working output, evidence, and present boundary are written together.
Maturity: Direction
No Digital product is published today; this entry is not a product announcement.
Next validation: Validate the first product with an inspectable release that meets all four Digital ledger criteria.
FIG. 03
A direction for bounded joint feasibility work with a data owner and domain expert in food, agriculture, biotechnology, or environmental systems.
Maturity: Direction
Claims no laboratory, field, or regulatory authority and promises no scientific or environmental result.
Next validation: Run one bounded joint feasibility study on a measurable question with a qualified domain partner and data owner.