The technical partner who builds your business’s systems.

We work across three domains — from a website to an operation, from a digital product to a scientific study. Every engagement starts with a written scope, is delivered in stages, and ends up owned by you. We do not guarantee outcomes; we write down the work and its limits.

Describe a problem See how we work

Three domains, one way of working.

The three are not separate businesses. What we learn in operations goes into the digital products, and the method we build in technology informs the decisions in both. Each domain gains its own depth over time.

Business

We build the digital and institutional side of a business around how the work actually runs. Most engagements start with a website and extend into the operation behind it.

Who it is for: Hotels, food and beverage venues, small businesses
Where it starts: Digital presence: site, content, contact channels
Where it goes: Booking, operations, reporting, and automation
Categories: Hospitality · Food and beverage · Small business — more as real work creates them

See the business categories

What we build

Multilingual website and content infrastructure
Booking, order, and appointment request flows
Direct contact: WhatsApp, phone, forms, map listing
Menu, price, and opening-hours management you update yourself
Google business profile and search visibility
Photography editing and content preparation
Operational data brought into one panel
Repeated work automated safely
Reporting and decision-support screens
A brand and corporate identity that stays consistent online

Digital

Asopel’s own digital products: applications, software products, and ambitious digital projects. Each one states the stage it is at.

What is here: Applications, software products, digital projects
Method: Systems engineering
Maturity: Labelled live, prototype, internal, or direction
Boundary: Nothing unlabelled is described as a product

Explore the digital products

What we develop

Web applications and internal tools
API and third-party system integrations
Data flows, cleaning, and synchronisation
Automation and workflow engines
Decision-support and monitoring interfaces
Reusable system components
Design system and component library
Tests, documentation, and a handover package

Technology

Where scientific work turns into practice. From biotechnology to applied physics, this domain talks about the problem and the method, and does not promise the result in advance.

What it does: Applied research, feasibility, scientific computing
Method: Applied science
How it starts: One measurable question and written assumptions
Boundary: No result before validation, no regulated call without an expert

Explore the technology domain

By which methods

Modelling and simulation
Experimental design and scenario comparison
Scientific computing and reproducible analysis
Data preparation and data-quality assessment
Feasibility studies and technical assessment
Measurement design and validation plans
Computational infrastructure and automation

We clarify the problem before choosing the technology.

Not every problem fits a ready-made product or one technology. We first look for the decision, workflow, or uncertainty that needs to change.

The data is scattered: When information lives in different files, tools, or people’s heads, we begin by creating a shared working surface.
The process is fragile: When work depends on one person or a repeated manual step, we design a reliable flow with visible states.
The decision is uncertain: When a model, experiment, or measurement is needed, we make assumptions explicit and start with a small test.

We say what works, what was tested, and what is still an idea.

Every piece of work is at a different stage. These labels explain what a visitor is actually seeing today.

FIG. 01Project

Bilingual site foundation

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

Evidence: A live bilingual Next.js application with automated static checks.
Current state: This is Asopel’s working infrastructure, not a general-purpose product.
Next test: Carry the content and release controls into new business areas.

FIG. 02Demo

Synthetic operations system

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

Evidence: Deterministic synthetic data and state transitions running in the browser.
Current state: Available in the lab for inspection; it is not a production service or ready-made product.
Next test: Test which problem classes could become a real feasibility engagement.

Open the operations system

FIG. 03Method

Evidence workspace

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

Evidence: Internal documentation and repeatable review checklists.
Current state: An internal working method, not an independent software product.
Next test: Define a safe sharing format for client feasibility work.

FIG. 04Product direction

Reusable operational systems

Avoiding a fresh build for every similar data and workflow problem.

A future solution direction that could adapt to different organisations; it is not productised yet.

Maturity: Direction

Evidence: A problem class and synthetic demo; no market or client outcome claim.
Current state: Not sold or supported as a product.
Next test: Validate it through a paid feasibility study against a real problem.

Visit the lab

We reduce the problem before we grow the system.

Instead of hiding uncertainty, we agree on the question to answer and the evidence that would be enough.

We listen to the problem

We separate the goal, current workflow, decision points, constraints, and unknowns.

We establish feasibility

When needed, we use a small data study, model, prototype, or architecture test to measure uncertainty.

We write the scope

Working output, responsibilities, price, timing, assumptions, and next steps become explicit.

We build the system

We develop the approved scope, document its boundaries, and deliver a usable system.

What we commit to

Written scope

Before work starts, what will be done, what will not, the price, the timing, and the responsibilities are all in writing. No line item appears later as a surprise.

Staged delivery

Every stage produces something you can look at. Nothing is held back to be handed over in one piece at the end.

You own it

Code, data, domain, and accounts are opened in your name and handed over with documentation. We hold no lock.

No outcome guarantee

We commit to the work, not to the result. You will not see us promise bookings, revenue, or a search ranking — because nobody can promise those honestly.

Who is behind this approach

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 founder-led today. New collaborators or specialists are included only when their roles and contributions are clear.

Registered business details

Registered name: Fırat Durak – Asopel Dijital Çözüm Ofisi
Address: Dicle Mah. 22. Cad. No: 12, Öden 1 Apt. Kat: 3, Daire: 16, Silopi/Şırnak
Tax office and number: Silopi Vergi Dairesi Müdürlüğü · 3140918320
Phone: +90 544 385 87 20
Email: tech@asopel.com

Describe the problem you want to solve.

A short summary is enough. Do not send secrets, personal sensitive data, or files; we first need to understand the problem and its context.

Send a project brief