Datahub System

Istanbul · Data and software engineering

Data you can decide on.
Software people want to use.

We build the warehouse underneath your reporting and the product in your customers’ hands — two disciplines, one team, held to the same standard.

Start a conversation See what we do

  • Oracle
  • Databricks
  • Delta Lake
  • React
  • React Native
  • PostgreSQL

Two practices

We do two things, and we do them properly.

Most of our work sits where the two meet: an application that has to be trusted by a reporting layer, or a warehouse that has to answer to a live product.

01

BI & Data Warehousing

Modelled, governed and fast — on Oracle and Databricks.

For teams whose numbers are argued about more than they are used.

  • Dimensional and Data Vault models that survive the next reorganisation.
  • ELT pipelines on Databricks and Oracle: batch, incremental and streaming.
  • Lakehouse architecture — Delta tables, medallion layers, Unity Catalog governance.
  • Migration from a legacy Oracle warehouse to a lakehouse, without stopping the reporting.
  • Semantic layers and dashboards the business actually reads.
  • Performance and cost work: partitioning, indexing, query tuning, cluster sizing.

What changes

One set of numbers, published on a schedule people can plan around, with a lineage you can follow back to the source system.

  • Oracle
  • Databricks
  • Delta Lake
  • PL/SQL
  • Spark
  • dbt
  • Airflow
  • Power BI
02

Web & Mobile Development

From a blank page to a product in the stores.

For teams with a product to launch and no appetite for a rebuild in two years.

  • Product discovery: scope, flows and a build you can afford.
  • Web applications built to load fast and stay maintainable.
  • iOS and Android applications from a single codebase.
  • APIs, authentication, payments and the operational plumbing behind them.
  • Design systems, accessibility and multi-language support from day one.
  • Release, monitoring and a handover that makes the system yours.

What changes

A product in production with tests around it, a deployment anyone on your side can run, and a codebase a new developer can read.

  • TypeScript
  • React
  • React Native
  • Node.js
  • PostgreSQL
  • Cloudflare
  • CI/CD

The work

Three problems we are usually called about.

Described as problems rather than as case studies: most of this work sits inside other people’s businesses, and the shape is more useful to you than the logo would be.

Data warehouse

Reporting nobody trusts

01
Three departments produce three different revenue figures, each defensible, none reconcilable. Month-end becomes an argument, and the argument is settled by whoever exports last.
02
We trace each figure back to its source system, agree a single definition with the people who own it, and rebuild the model so the definition lives in one place instead of six spreadsheets.
03
One number, one owner, one place it is calculated — and a lineage anybody can follow when they want to challenge it.

Lakehouse migration

An Oracle warehouse that stopped scaling

01
The nightly load no longer finishes before the working day. Every new source makes it worse, and the obvious answer — bigger hardware — has already been bought once.
02
We move the heavy processing to Databricks in medallion layers while Oracle keeps serving the reports, then cut over one subject area at a time. Nothing goes dark in the meantime.
03
Loads that finish, sources that can be added without renegotiating the window, and a cost you can see per workload instead of per server.

Product

A product that has to exist on two platforms at once

01
The idea is clear, the budget is finite, and it has to work on the web, on iOS and on Android — without three teams and three roadmaps.
02
One codebase across web and mobile, a design system agreed before the screens multiply, and releases in increments you can put in front of real users early.
03
A product in the stores and on the web from one repository, with the operational parts — auth, payments, monitoring — already in place rather than promised.

How we work

Small steps, visible from the outside.

Every engagement runs the same way, whether it is a warehouse migration or a first release.

  1. 1

    Understand

    We start in your data and your workflow, not in a slide deck. A short discovery surfaces the real constraints — the ones nobody writes down.

    Usually one to two weeks, fixed price.

  2. 2

    Shape

    You get an architecture, a plan broken into reviewable steps, and a number you can budget against before anything is built.

    You can stop here and take the plan elsewhere.

  3. 3

    Build

    Work lands in small increments you can see running. Nothing stays “nearly done” for a month.

    Two-week increments, each one demonstrable.

  4. 4

    Hand over

    Documentation, tests and a walkthrough. You keep the system and the knowledge — not a dependency on us.

    Support afterwards is optional, never assumed.

Fit

Where we fit, and where we do not.

Saying this out loud saves everybody a first meeting. We would rather point you elsewhere than take work we would do badly.

A good fit

  • A warehouse or a product with a defined owner on your side.
  • Work measured in months, where we can go deep rather than wide.
  • Teams who want the system handed over, not held hostage.
  • Existing systems that need rescuing as often as new ones.

Not a good fit

  • Body-shopping: a developer placed in your office by the hour.
  • Very large programmes needing a bench of twenty people next month.
  • Fixed-price builds against a specification nobody is allowed to question.
  • Platforms outside our two practices, where you deserve a specialist.

What you can count on

Three commitments we make in writing.

One
senior owner per engagement
The person who designs your system is the person who builds it.
Two weeks
between working increments
You see the thing running long before it is finished.
100%
of the source is handed over
Code, documentation and infrastructure, in your accounts.

Technology

What we build with.

Chosen for what they cost to run and to maintain over five years, not for what is fashionable this year.

Data platform

  • Oracle Database
  • Databricks
  • Delta Lake
  • Apache Spark
  • PL/SQL
  • Apache Airflow
  • dbt
  • Kafka

Modelling & reporting

  • Star schema
  • Data Vault 2.0
  • Unity Catalog
  • Power BI
  • SQL

Product

  • TypeScript
  • React
  • React Native
  • Expo
  • Node.js
  • PostgreSQL
  • Prisma

Delivery

  • Cloudflare
  • Docker
  • GitHub Actions
  • Terraform
  • Playwright
  • Vitest

About

A small practice, on purpose.

Based in
Ataşehir, Istanbul
Working with
Turkey and Europe, remote
Languages
Turkish, English

Datahub System is a senior-led engineering practice based in Istanbul. We keep the team deliberately small, so the person who designs your system is the person who builds it — and the person you talk to when something has to change.

That shape has a cost and a benefit. We take on a limited number of engagements at a time. In return you get continuity: no handover between a sales team and a delivery team, no rotating juniors, no context lost between phases.

When a project needs more hands or a specialism we do not carry, we bring in partners we have worked with for years — and we stay accountable for the result.

Questions

The things people ask first.

How do you price work?

Discovery is a fixed price agreed before it starts. Delivery is either a fixed price per step, once the steps are known, or a monthly rate for open-ended work. You are never billed for a step you have not agreed to.

How long does an engagement take?

Discovery is one to two weeks. A first useful increment usually lands within a month of starting to build. Warehouse migrations run in subject areas over several months; a first product release is typically three to six months, depending on scope.

Can you work alongside our own developers?

Often that is the better arrangement. We can lead the architecture and review the work while your team builds, or take one subject area end to end while your team takes another. Either way the conventions are written down so both sides build the same way.

Will you take over something somebody else built?

Yes, and a good part of our work is exactly that. It starts with a short assessment: what is there, what is load-bearing, what has to be replaced first. You get that assessment in writing whether or not you go on to work with us.

Who owns the code?

You do, from the first commit. Repositories, cloud accounts and credentials are yours throughout — we work inside them rather than handing something over at the end.

Do you work on site?

We are in Ataşehir and can be in a room in Istanbul when it helps — a kick-off, a workshop, a difficult review. The rest runs remotely, which is how most of our clients in Turkey and Europe prefer it.

What happens after launch?

A handover with documentation, tests and a walkthrough, so your team can run it without us. If you would rather we stayed close, support is a separate monthly agreement with an agreed response time — never an automatic renewal.

Contact

Tell us what you are trying to build.

A short description of the problem is enough to start. We read every message and reply within one business day.

Office
Küçükbakkalköy Mah. Dereboyu Cad.
R5 Blok No: 3A/48
Ataşehir / İstanbul
Hours
Monday to Friday, 09:00–18:00 (GMT+3)

Send a message

Prefer email? Write to contact@datahubsystem.com

Your message and contact details are used only to answer your enquiry and are not shared with third parties. Write to us to have them deleted.