# Haluk Demirhan > Haluk Demirhan is the founder of Commercium Limited (https://thecommercium.com), an independent app studio in London. Statistician by training, founder by practice. ## Facts - Founder of Commercium Limited, London, United Kingdom. Runs it as its only founder, with AI agents and modern development tools. - Before Commercium: co-founded an independent mobile app studio in London and scaled its flagship product to 100K+ downloads and $50K+ monthly revenue. - Education: MSc, Management of Business Information Technology, University of Greenwich; BSc, Statistics, Marmara University. - Open source: datagrade, an R package for scored data quality assessment (https://github.com/ohalukdemirhan/datagrade). - GitHub: https://github.com/ohalukdemirhan - Medium: https://medium.com/@halukdemirhan - Contact: contact@halukdemirhan.com ## Commercium apps - Three Seals (https://threeseal.com): An element card duel in a night temple, fought by karate animals. - 369 Zone (https://369.zone): A daily 3-6-9 writing ritual that keeps one intention in front of you. - SlideForge (https://slideforge.cloud): Type a topic, get a finished, designed presentation. ## Writing - [Where the planets are, in plain Dart: an engine I wrote, tested and opened](https://halukdemirhan.com/writing/pure-dart-ephemeris/) (2026-10-12): Why I replaced a C library with about 600 lines of Dart and a test, how close it gets to the reference, and why I released it under the MIT licence. - [Why I believe the permanent underclass is coming](https://halukdemirhan.com/writing/permanent-underclass/) (2026-10-08): AI is aimed at the last work people moved into. A statistician who builds software on why a permanent underclass is the default, within fifteen years. - [Three Seals: Dojo Duel, and what one person made](https://halukdemirhan.com/writing/three-seals-dojo-duel/) (2026-10-01): A card duel fought by karate animals, made by one founder: the design, the art, the code, the shop and the video. - [One founder, many worlds: how I run an app studio with AI agents](https://halukdemirhan.com/writing/one-founder-many-worlds/) (2026-09-26): Why I started Commercium, how the work is split between me and AI agents, and what never gets delegated. - [One gesture, one step: a scroll story that does not fight your hands](https://halukdemirhan.com/writing/one-gesture-one-step/) (2026-09-26): The Commercium home page moves one chapter per swipe, wheel notch or key press. How the step lock tells a new gesture from trackpad inertia, and when it gets out of the way. - [The most expensive problem in a startup isn’t always the market](https://halukdemirhan.com/writing/the-most-expensive-problem-in-a-startup/) (2026-08-11): Why misalignment between founders is harder to survive than a bad product decision, and the governance that keeps disagreement productive. - [MCP: AI’s “USB-C” moment](https://halukdemirhan.com/writing/mcp-ais-usb-c-moment/) (2026-08-10): How the Model Context Protocol became a shared standard in 20 months, and why its governance layer matters as much as the integration. - [Aim to Moon, day 1: I launched my app (and broke it on the same day)](https://halukdemirhan.com/writing/aim-to-moon-day-1/) (2026-04-23): Launching a subscription app as a solo founder, and breaking payments on launch day. - [From data-driven organisations to AI-driven individuals](https://halukdemirhan.com/writing/from-data-driven-organisations-to-ai-driven-individuals/) (2026-01-28): How the habits of data-driven organisations are moving to individuals who run their work as systems with AI. - [Why every startup project must be data-driven](https://halukdemirhan.com/writing/why-every-startup-project-must-be-data-driven/) (2025-05-21): Why startups that measure, test and let evidence decide outperform those that run on intuition. ## Optional - [Every essay in full](https://halukdemirhan.com/llms-full.txt) # Essays in full --- Source: https://halukdemirhan.com/writing/pure-dart-ephemeris/ ## Where the planets are, in plain Dart: an engine I wrote, tested and opened Haluk Demirhan · 12 October 2026 Kairos (https://kai-ros.life) is a Commercium app that draws the sky of any moment and any place. To do that it has to know where the Sun, the Moon and the planets were, are or will be, to a fraction of a degree, on a phone, offline. This post is about the engine that does that sum, how I decided it was accurate enough, and why I released it as kairos_ephemeris (https://github.com/The-Commercium/kairos-ephemeris), free for anyone to use. ### The usual answer, and its cost Software that needs planetary positions almost always uses the Swiss Ephemeris (https://www.astro.com/swisseph/). It is precise, mature and well documented, and I have nothing against it. It does come with two costs for an app like this one. The first is the build. It is a C library, so a Flutter app reaches it through FFI on every native platform and through WebAssembly on the web. That means a native toolchain on every target and one more moving part in every release. The second is the licence. The Swiss Ephemeris is dual licensed. You can take the AGPL, which asks the whole app built on it to be released under the AGPL or a compatible licence. Or you can buy a professional licence from Astrodienst; the current contract asks CHF 700 for an unlimited number of projects, valid for six years. That is a fair price for a company. For an open-source project, or for anyone who would rather not tie a closed app to a contract, it is still a decision to make before the first line of code. When I looked on pub.dev, the Dart options were bindings to that same C library. I could not find an engine in plain Dart, under a permissive licence, that also handled house cusps. ### What I built The engine is about 600 lines of Dart plus generated coefficient tables, and it uses nothing beyond dart:math. - Planets. The VSOP87 theory of Bretagnon and Francou, in the truncated form published by Astronomy Engine (https://github.com/cosinekitty/astronomy), Don Cross’s MIT-licensed library. On top of it sit light time, annual aberration, precession and nutation, following Jean Meeus’s Astronomical Algorithms. - The Moon. The Montenbruck and Pfleger lunar theory, again as ported by Astronomy Engine. - Pluto. No short series describes it well, so the engine samples Astronomy Engine’s simulated orbit every 20 days from 1799 to 2201 and interpolates. - Time. Clocks follow the Earth’s rotation, which slows down irregularly. The Espenak and Meeus polynomials bridge atomic time and Earth time (a quantity called Delta T). - Houses. Sidereal time, then the Ascendant, the Midheaven and the cusps, with Placidus solved by iteration. Inside the polar circles Placidus has no answer, so the engine falls back to Porphyry and says so. A short Python script regenerates the tables from Astronomy Engine, so nothing in them is typed by hand. ### The reference as an examiner, not a dependency A sum like this is easy to get slightly wrong in ways no one notices: a sign error in aberration, a time scale mixed up, a cusp in the wrong quarter. So I let the reference library examine the engine instead of running inside it. A second script, run only on my own machine, asks the Swiss Ephemeris for 400 random moments between 1850 and 2149 at random places from 60° south to 65° north, plus five fixed cities. It writes the answers to a file. The test suite asks the engine the same 400 questions and fails if any answer drifts past its limit. Kairos does not ship without passing it. for (final b in Body.values) { expect(worst[b]!, lessThan(limits[b]!), reason: b.name); } expect(retrogradeMismatches, 0); These are the worst differences in longitude across all 400 cases, in arcminutes (one arcminute is a sixtieth of a degree): Body Worst difference Sun 0.16′ Moon, up to 2025 0.08′ Mercury to Pluto 0.35′ at most Lunar nodes 0.65′ at most House cusps, Ascendant, Midheaven 0.09′ The direction of motion, forwards or retrograde, matched the reference in every case. ### How accurate is accurate enough? You could keep improving an engine like this for years. The question that told me when to stop came from the input. A moment in the app is a date and a time, usually to the minute. The Moon, the fastest body, moves about half an arcminute in a minute of time, so the worst Moon difference up to 2025 is about the distance it travels in nine seconds. The Ascendant turns on average about fifteen arcminutes a minute, so its 0.09′ is less than half a second of the clock. The screen shows degrees and whole minutes. In other words, any error that matters comes from the time someone types, not from the engine. Beyond that point, more precision costs code and app size and changes nothing a person can see. I wrote the limits into the test so that the line stays where I drew it. ### The future is a forecast One result surprised me at first. For dates after 2025, the Moon’s difference grows, to about two arcminutes by 2149. Neither library is wrong. Delta T has been measured for the past but can only be forecast for the future, and the two libraries use different forecasts. The Moon moves fastest, so it shows the gap first. I could have hidden this by testing only past dates. Instead the test widens the Moon’s limit a little for every year past 2025, and the README says why. A table that shows only the comfortable cases is not much of a test. ### Limits The engine is geocentric: it gives the sky as seen from the centre of the Earth, without the small shift for where on the surface you stand. It covers 1800 to 2199. It does not do asteroids, fixed stars or eclipse paths. These limits are fine for an app that draws the sky. They are not fine for navigation, and the README says so. ### Why I opened it The engine stands on open work: VSOP87 from the Bureau des Longitudes, decades of published algorithms, and Don Cross’s careful ports in Astronomy Engine. Releasing the Dart version, with its test and its worst cases, is a fair return. The repository holds the engine, the tests, the reference file and both scripts, so anyone can rerun the comparison, and its licence file carries Astronomy Engine’s notice next to Commercium’s. Three things from this work apply well beyond astronomy: - Set the error budget from the input, not from the best library you can find. - Make the reference library an examiner: let it check your code in a test instead of shipping inside your app. - Publish the worst case and its reason, not the average. The code is at github.com/The-Commercium/kairos-ephemeris (https://github.com/The-Commercium/kairos-ephemeris), and Kairos (https://kai-ros.life) is where it runs. --- Source: https://halukdemirhan.com/writing/permanent-underclass/ ## Why I believe the permanent underclass is coming Haluk Demirhan · 8 October 2026 There is a countdown going around in technology circles. It reads: you have eighteen months to escape the permanent underclass. The number changes with whoever is posting it. The idea does not. Artificial intelligence will soon do most paid work, wages will stop being a way up, and whoever has not secured a foothold by then will stay where they are. In April, Jasmine Sun's reported essay in The New York Times (https://www.nytimes.com/2026/04/30/opinion/ai-labor-work-force-silicon-valley.html) showed how far the idea has travelled inside the industry. It opens with a sentence that is hard to forget: Most people I know in the A.I. industry think the median person is screwed, and they have no idea what to do about it. I build software for a living, with the same tools that sit at the centre of this fear. I think the people in that sentence are right. Where I differ from the countdown is the number. Eighteen months is a sales pitch. My own estimate is fifteen years at the most. That is not a comfort. Fifteen years is shorter than a working life: a child starting school today will look for a first job inside it, and most people reading this will still be working when it closes. I trained as a statistician long enough to recognise a default when I see one, and this is one. ### The argument The careful version is older than the meme. Rudolf Laine's essay By default, capital will matter more than ever after AGI and The Intelligence Curse (https://intelligence-curse.ai/), written with Luke Drago, set it out. If machines can do human work, the value of a person's labour falls and the value of owning the machines rises. For most people in history, work has been the only ladder. Take the rungs away and the people at the bottom stay at the bottom, while the people who own things keep compounding. I find this hard to argue with. The first reason is a chart. ### The chart Every year the Stanford AI Index compares the best models with a human baseline on a set of benchmarks. The dashed line at 100% is the human. What a statistician notices is not that the lines cross it. It is how fast they cross it, and how that speed keeps rising. Image classification took about three years to climb from 90% of the human baseline to parity, from 2012 to 2015. Multitask language understanding took about five, from 2019 to 2024. PhD-level science questions went from under half of the expert baseline to above it in a single year. Autonomous software engineering went from about 65% to nearly 100% in one year. Computer use, an agent operating a desktop the way a person does, went from single digits to about three quarters, also in one year. I know the objections, because I would raise them myself. The benchmarks are selected, and the ones that get solved are the ones that end up in charts like this. "Human baseline" means different humans on different tests, from crowd workers to domain experts. Test questions leak into training data. And a benchmark is not a job. All of this is true, and none of it explains away the newest lines. The early benchmarks measured seeing and reading. The newest measure work: writing software and operating a computer. Those are the lines with the steepest slopes, and they are the ones that matter for wages. The chart also stops in 2025. Today, a model that leads the public rankings is often overtaken within two to four weeks. ### Adoption is no longer slow The strongest comfort used to be diffusion. Electricity took decades to change factories, because the factories had to be rebuilt around it. AI was supposed to be the same: capable in the lab, slow to reach real work. Look at how fast the industry agreed on the plumbing. Anthropic published the Model Context Protocol, an open standard for connecting models to tools and data, in November 2024. Within months its rivals had adopted it, and thirteen months after launch it was handed to a new Linux Foundation body, with OpenAI, Google, Microsoft and AWS among its backers. Competitors do not agree on a standard that quickly unless they expect to need it. The link between the model and the systems where work actually happens is being built at the speed of software, not the speed of factories. ### There is no next room to move into The usual reply is history. In 1930 Keynes warned of "technological unemployment". In 1964 a group of scientists and economists sent President Johnson a memo, The Triple Revolution, predicting a permanent class with no work to do. Both were wrong, because people kept moving into new kinds of work. But look at where they moved. Machines took the work of muscle, so people moved into routine thinking. Computers took routine thinking, so people moved into judgement, language, analysis and care. Every wave left a room the machines could not enter. This wave is aimed at that room itself. When the tool can read, write, reason and plan, there is no obvious next room. The economist Wassily Leontief made the comparison decades ago: the horse was not retrained when the tractor arrived. Its work simply ended. "It never happened before" is a base rate. Base rates are useful until the mechanism changes, and this time the mechanism has changed. ### Cheap to build is not the same as easy to climb The hopeful view says the tools are rented by the month, at the same price for a student in Istanbul as for a fund in London, so everyone gets the same leverage. I see that leverage in my own work every day. Things that once needed a team, a budget and a year can now be made by one person. That is good news for the one person. It is not good news for the team that was never hired. And when everyone can build, building stops being scarce. What stays scarce is what the builder does not get from a subscription: an audience, distribution, a brand people already trust, data, and the capital to wait while something finds its market. Those belong to whoever already has them. Building has become cheap. Being found has not. ### The bottom rungs go first Mobility is not about the top of the ladder. It is about the bottom. Entry-level roles are where people learned a trade while being paid for it: the junior developer, the trainee analyst, the assistant who became the manager. That is exactly the work the new tools do best, and it is the first work that stops being hired. A ladder with its lower rungs missing still has a top. The people already on it are fine. Nobody new gets on. Do that for a generation and the result looks permanent, even though no single decision made it so. ### Watch the median, not the mean Statisticians learn early that an average can rise while most people fall behind. Gains from software tend to follow a power law: a few winners take most of the value. AI can raise total output enormously and still leave the median worker with a smaller share than before. Labour's share of income in many rich economies has been drifting down for decades. This technology pushes in the same direction, faster. That is why the sentence in the Times names the median person. The median is the right statistic, and it is the one most likely to be left out of the headline numbers. ### Cheap is a phase Technology usually gets cheaper after it arrives, and AI seems to follow the rule: last year's capability now costs a fraction of what it did. But last year's capability is not what does the work. The frontier does, and the frontier has not become cheap. I read today's prices as a land grab. The largest labs are reported to be losing billions of dollars a year, paid for by investors who expect that money back. Watch what the labs are doing with it. They are no longer only selling tools. They are buying companies: by the spring of 2026, OpenAI alone had made almost as many acquisitions as in the whole of 2025 (https://news.crunchbase.com/ma/data-openai-2023-2026-acquisitions-open-source-astral-promptfoo/), in developer tools, testing, health and finance, and its rivals are doing the same. They are building products that do the work themselves, not products that help someone else do it. When a lab sells the work, the small builder is no longer its customer. They are its competition, and there is little reason to keep the best intelligence cheap for a competitor. Today the student in Istanbul and the fund in London pay the same price. I do not expect that to last. When the land grab ends, I expect the frontier to become expensive, and access to it to gather around a few large companies and the people who own them. That is the real loss: not that the tools disappear, but that the best of them become something only the largest players can afford to run at scale. ### Believing it is not the same as accepting it I believe the permanent underclass is the default outcome. A default is what happens when nobody chooses otherwise. Sun's conclusion is the one I share: the production of a social underclass is a policy choice. That is exactly why it is worth saying out loud now, while the choice is still open, instead of after the ladder is gone. For individuals, I do not think the answer is panic or a gamble before a deadline. It is a change in what you aim for: - Own something. A product, a share, a body of work, an audience. Wages are what the machines compete with; ownership is what they work for. - Build while building is cheap. The tools that threaten the job are, for now, the same tools that let one person make something of their own. - Earn trust. When anyone can produce anything, people choose who they believe. Trust is slow to build and hard to copy. - Take part in the argument. How the gains are shared will be decided by people. It is better decided early, and by many. The countdown is wrong about one thing. There is no single moment when the door closes. It closes over years, not months, fifteen at the most by my estimate, one unhired junior at a time. That is the bad news. The good news is that something that closes slowly can still be held open. --- Source: https://halukdemirhan.com/writing/three-seals-dojo-duel/ ## Three Seals: Dojo Duel, and what one person made Haluk Demirhan · 1 October 2026 I'm the solo founder of Commercium (https://thecommercium.com), a one-person app studio in London, and I made all of Three Seals: Dojo Duel (https://threeseal.com): the game design, the card and belt system, the art direction and character rigs, and the single codebase that ships to iOS, Android and the web. I set up the RevenueCat membership and in-app purchases, localised the game into 11 languages, built the website and made the demo video from the game's own animations. I worked with Claude Code as my engineering partner throughout. That paragraph is what I wrote in the "describe your contribution" box when I entered the game in RevenueCat's Shipaton 2026. The full write-up is on the project page on Devpost (https://devpost.com/software/three-seals-dojo-duel), and there is a demo video (https://youtu.be/lloIALkoIeU). This is the shorter, personal version. ### The game Three Seals is a small card duel. Each card has an element and a number: fire burns wood, wood soaks up water, water puts out fire, and if the elements match the higher number wins. Every card you win goes on your shelf as a seal. Three seals of one element, or one of each element in three different colours, and the duel is yours. It is fought by karate animals in a temple at night. You bow in, the gate closes, the clock runs, and at the end both fighters bow and say "Oss!". I wanted a game you can play in two minutes on the bus, but one that still feels like a proper dojo. ### What one person made - The design. Three masters with their own habits, belts from white to black and then dan ranks, three special moves, a daily duel and monthly events. Losing never takes points away. - The art. Thirteen animal avatars drawn as hand-built rigs, a wardrobe of outfits, and a scene for every clash. - The code. One codebase with no game engine, wrapped for iOS and Android and served on the web. Every duel is seeded, so the same seed plays the same match, and a test can play whole matches before each release. - The business. The whole game is free. You pay for how you look, never for how strong you are: a Dojo Membership and tokens for outfits, run through RevenueCat. Belts, masters and card power are never for sale. - The rest. Eleven languages, the store pages, the website and the video, which is rendered from the game's own characters. ### What was hard The game itself was the easy part. The hard part was making a new player understand in thirty seconds why they won. In early tests people did not know what the dots on their shelf meant, so I turned them into element tiles with empty slots for the seals still missing, and the winning three now light up one by one before the bow. The "Oss!" was a smaller problem with a simpler answer. No free sound library had one, so it is my own voice. ### Where the machine fits I have written before about how the work is split. Three Seals is that split in practice. Claude Code wrote and tested a great deal of the code with me. What to build, what good looks like and whose name is on the release stayed where they always stay. You can play it in a browser (https://play.sealduel.com) now, and read the whole story on Devpost (https://devpost.com/software/three-seals-dojo-duel). --- Source: https://halukdemirhan.com/writing/one-founder-many-worlds/ ## One founder, many worlds: how I run an app studio with AI agents Haluk Demirhan · 26 September 2026 I started Commercium (https://thecommercium.com) to answer one question: how far can one person go, now that software can be built with so much leverage? The studio's north star is the short version of that question. Make what should not be possible for one person. Commercium is an independent app studio in London. It has one founder, and it ships apps that each live in their own world: a card duel in a night temple, a calm daily writing ritual, a presentation maker. This is how the work actually gets done. ### Start with the idea, not the team A small studio used to mean a small ambition. You could have one good idea, or you could have a team. Today, much of the work that once needed a team can be described precisely enough for a machine to do it: writing and refactoring code, running tests, preparing releases, checking that a page works on a phone at 320 pixels wide. So I start from the idea and ask what it needs, not who I would have to hire. AI coding agents do most of the systematic work. An internal orchestration layer keeps track of every project, ticket and decision, so that context survives from one working session to the next and nothing depends on memory. Every task is written as a self-contained runbook: what to do, how to check it, and what counts as done. ### Measure before I assume I trained as a statistician, and it shows in how the studio works. Every app is instrumented from its first release. A launch is not the end of the process; it is the first honest source of information. The numbers decide what gets built next, and when the evidence disagrees with my instinct, the evidence usually wins. I learned this the hard way before Commercium. At an independent mobile app studio in London that I co-founded, we scaled the flagship product to more than 100,000 downloads and more than $50,000 in monthly revenue. The lesson I kept was not a growth trick. It was the habit of measuring honestly and early. ### What never gets delegated Machines are leverage, not the point. Some things stay with me, always: - What to build. Choosing the problem is the most important decision, and it is not a task. - What good looks like. The look, the voice and the feel of each app are judgement calls. - Responsibility. My name is on the company and on every release. Privacy, store review and the promises we make to people who use the apps are mine to keep. ### Small, sharp and finished Leverage makes it tempting to build everything. The discipline is the opposite: keep each app to one clear job and finish it properly. That is why every Commercium app gets its own world, with its own colours, type and characters, instead of a shared template. Small scope is what lets one person hold the quality bar high. ### Why say all this out loud Because it is the honest description, and because it is the interesting part. Commercium is not pretending to be a fifty-person company. It is one founder and a set of very capable tools, and the apps are the proof of what that combination can do. If you want to see them, start at thecommercium.com (https://thecommercium.com). If you want to talk, write to me. --- Source: https://halukdemirhan.com/writing/one-gesture-one-step/ ## One gesture, one step: a scroll story that does not fight your hands Haluk Demirhan · 26 September 2026 The Commercium home page (https://thecommercium.com/) tells the studio’s story in steps. The hero, a short statement, then one chapter for each app. Every gesture moves you exactly one step: one notch of a mouse wheel, one swipe on a trackpad, one press of an arrow key, one swipe on a phone. This post is about how that works, and about the times it deliberately does nothing. ### The problem with scroll stories A pinned, scroll-driven page looks lovely in a screen recording and often feels wrong in the hand. The usual failure is a trackpad. A single two-finger swipe on a Mac produces a burst of wheel events and then a long, fading tail of inertia events. If every event can advance the story, one swipe skips three chapters. If the page ignores events for a fixed time, a fast reader feels stuck. Scroll-jacking libraries solve this by taking over scrolling completely. I did not want that. The page should scroll natively everywhere outside the pinned story, and the story should hand control back the moment you reach either end. ### What counts as a new gesture The controller listens to wheel, touch and key events. For the wheel, it first normalises the delta: a browser can report it in pixels, lines or pages, so a line becomes 40 px and a page becomes the viewport height. Then it decides whether this event starts a new gesture or belongs to the one already moving. An event counts as new if: - more than 250 ms have passed since the last wheel event, or - the direction has changed, or - at least 320 ms have passed since the last step, the delta is at least 18 px, and it is at least 1.75 times the previous delta, or - the same timing and size hold and a short moving average of the last 10 deltas has risen above the long average of the last 70. The last rule is the one that matters most on a trackpad. Inertia decays: each event is a little smaller than the one before, so the short average sinks below the long one. A real second swipe rises. Comparing the two catches a quick second swipe that arrives before the first one’s tail has finished. const isNew = gap > NEW_GAP || // 250 ms of silence dir !== this.lastDir || // a change of direction (sinceStep >= MIN_STEP_GAP && abs >= MIN_DELTA && abs >= RISE * this.lastAbs) || (sinceStep >= MIN_STEP_GAP && abs >= MIN_DELTA && rising); ### Swallow, then settle Once a step starts, every further event is swallowed until it finishes. That single rule is what stops inertia from skipping a chapter. I test it with a simulated trackpad swipe of 73 wheel events with a long decaying tail: it moves the story exactly one stop. On a desktop, the step itself is a scroll tween of 0.6 seconds with a gentle ease in and out, and the scene’s animation follows the scroll position. On a phone, scrolling is frozen while locked and the scene’s timeline is tweened instead, over 0.5 seconds. Phones get the quicker, simpler motion because a finger expects the page to answer at once. ### Entering and leaving the story Two edge cases decide whether a step lock feels trustworthy. Entering. If you scroll towards a pinned section from outside it, a gesture that would carry you past its first stop lands exactly on that stop and locks. You never arrive halfway through a chapter. Leaving. At the first or last stop, one more gesture in the same direction releases the lock and normal scrolling carries on. A large jump, such as dragging the scrollbar or pressing End, releases it at once. The controller remembers your last direction for 800 ms, so when it has to choose which end of a section to land on, it chooses the one you were heading for. While locked, a small loop on each animation frame puts the scroll position back if momentum drifts it. On touch screens the page sets touch-action: none only while the story is locked, and restores it on release, so pinch zoom and normal panning work everywhere else. ### When the answer is no motion The best motion design includes a way out. - Reduced motion. If your device asks for reduced motion, the page never pins, never locks and runs no ambient loops. The chapters render as calm stacked sections with the same words, links and still images. - No JavaScript. The same stacked layout is what the server sends. Scripts only switch the motion layout on after they have started, and if the story has not taken over within five seconds, the page falls back to the stacked layout rather than leave anything hidden. - Pause. A Pause motion button stops every loop, scene and video on the page, in line with WCAG 2.2.2 (pause, stop, hide). Keyboard users get the same steps as everyone else: the arrow keys, Page Up and Page Down, Space, Home and End. The dot rail on the side is labelled, marks the current chapter for screen readers, and each chapter has a link of its own, such as /#three-seals (https://thecommercium.com/#three-seals). ### The budget A scroll story is easy to make heavy. I set a budget before I started and test it on every build: the home page’s HTML, CSS and JavaScript must stay under 200 KB compressed, and its JavaScript under 90 KB. At launch the home page’s JavaScript is about 74 KB compressed, and around a third of that loads only as you approach the chapter that needs it. Only transforms and opacity are animated, blur is applied to one layer at a time and never to video, and the Three Seals scene pauses when it is off screen. ### What I would tell anyone building one Test with real inertia, not just single wheel events; a synthetic swipe with a long tail finds bugs a mouse never will. Decide what happens at the edges before you tune the middle. And build the stacked version first: if the story reads well with no motion at all, the motion is a bonus rather than a crutch. The rest of the site follows the same rules. If you want to see the result, the Commercium home page (https://thecommercium.com/) is the whole demonstration. --- Source: https://halukdemirhan.com/writing/the-most-expensive-problem-in-a-startup/ ## The most expensive problem in a startup isn’t always the market Haluk Demirhan · 11 August 2026 · First published on Medium (https://medium.com/@halukdemirhan/how-co-founder-conflict-can-destroy-a-10k-month-startup-80082b795d7b) A startup can survive a bad product decision. It can survive a failed marketing campaign. What becomes significantly harder to manage is misalignment between the people responsible for deciding what the company becomes. In the early stages, startups naturally operate with a high degree of informality. Founders share responsibilities, decisions happen quickly, and agreements are often made through conversations rather than formal documents. That flexibility is useful when a company is small. But as the company grows, ambiguity becomes more expensive. A 2025 systematic literature review published in the Review of Entrepreneurship examined 43 studies specifically focused on conflict among entrepreneurial co-founders. The research highlights that founding teams have characteristics that make their conflicts different from those found in conventional teams, including informal power structures, ambiguity, competitive dynamics, urgency in decision-making and shared interpersonal history. That last point is particularly interesting. Founders are not simply colleagues. They often build the company before formal structures exist. Roles evolve while the product evolves. Influence develops organically. One founder may become more involved in technology, another in sales, another in operations. Decisions that were once made casually can eventually determine ownership, authority and the strategic direction of the company. This is where a disagreement about the business can become a governance problem. Research distinguishes between different forms of conflict within teams. Disagreement about tasks, strategy or execution can sometimes improve decision-making. The risk increases when disagreements become intertwined with unclear roles, informal power or competing expectations about authority and ownership. This is why governance matters. Founder agreements, IP assignments, equity and vesting arrangements, decision-rights frameworks and dispute mechanisms are not necessarily signs of bureaucracy. They are mechanisms for reducing ambiguity. A good founder agreement does not need to predict every possible future disagreement. It needs to answer the questions that become expensive when left unanswered: - Who owns the intellectual property? - How is equity divided and vested? - What is each founder responsible for? - Which decisions require mutual agreement? - Who has authority over specific areas? - What happens if a founder leaves? - How are disagreements resolved? These questions can feel unnecessary when everything is going well. They become much more important once the company has customers, employees, revenue, intellectual property or outside investment. Y Combinator similarly recommends discussing roles, titles, equity, responsibilities, commitment and long-term expectations before starting a company together. It also recommends testing the working relationship through a trial project and maintaining regular founder communication. YC also emphasises that its network is built on trust and shared values such as integrity, respect and accountability, and that founders are expected to act in good faith in all interactions. This includes being honest with co-founders, employees and investors, avoiding misleading or unethical behaviour, and respecting confidentiality. It also recognises that not every agreement in the early stages is formalised in writing; even informal or verbally made understandings between founders are expected to be honoured in good faith, as these “handshake agreements” often form the foundation of trust before legal structures are fully in place. There is also a broader management framework for collaborative relationships. ISO 44001:2017 provides a structured approach to establishing and managing collaborative business relationships, including partnerships, alliances and joint ventures. Its structure walks organisations through eight stages grouped into three broader phases: a strategy phase focused on internal readiness and understanding the case for collaboration, an engagement phase covering partner selection and joint value creation, and a management phase concerned with sustaining the relationship over time and planning an orderly exit when the partnership eventually ends. This does not mean founders should start with layers of corporate bureaucracy. It means that the informal assumptions that work at the beginning should eventually be converted into explicit structures as the company becomes more valuable. The strongest founding teams do not eliminate disagreement. They create enough clarity around ownership, responsibility and decision-making that disagreement can remain focused on the business. A startup does not need perfect founder alignment. It needs enough clarity for disagreement to remain productive. The principle is straightforward: Trust helps founders move quickly. Governance helps the company keep moving when decisions become difficult. This is why businesses need governance and documentation, not as a matter of individual preference, but as something essential to the survival of the company itself. Because sometimes the biggest risk to a growing company isn’t the market outside it. It’s the ambiguity inside it. You can find ready-to-use templates for several of these documents such as Agreements, Contractor Agreements, Employment Agreements, NDAs, MSAs and SOWs here: Startup Document Templates (https://drive.google.com/drive/folders/1CcEeR8rvuDmfgTsEb1kmq3Q5NuKNyaf_?usp=sharing) Templates are provided for general reference only and do not constitute legal advice. Sources - Ghanei, Y., Jaouen, A., Nakara, W. A., & Sammut, S. (2025). Exploring Conflict Dynamics in Entrepreneurial Founding Teams: A Systematic Literature Review and Future Research Agenda. Revue de l’Entrepreneuriat / Review of Entrepreneurship, 24(3), 93–125. - Y Combinator — Ethics: https://www.ycombinator.com/ethics (https://www.ycombinator.com/ethics) - ISO 44001:2017 — Collaborative business relationship management systems: https://www.iso.org/standard/72798.html (https://www.iso.org/standard/72798.html) --- Source: https://halukdemirhan.com/writing/mcp-ais-usb-c-moment/ ## MCP: AI’s “USB-C” moment Haluk Demirhan · 10 August 2026 · First published on Medium (https://medium.com/@halukdemirhan/mcp-ais-usb-c-moment-1a8c88bd8303) ### How a protocol got adopted this fast In November 2024, Anthropic released an open standard called the Model Context Protocol (MCP). Thirteen months later, in December 2025, Anthropic handed governance of it over to the Agentic AI Foundation under the Linux Foundation, meaning MCP stopped being one company’s specification and became a community-owned standard, the same way Linux, Kubernetes and other critical infrastructure eventually did. By March 2026, monthly SDK downloads had gone from 100,000 to 97 million (source: Knak (https://knak.com/blog/mcp-adoption-in-2026-what-marketers-need-to-know/)), and OpenAI, Google, Microsoft and Amazon had all shipped support for it. ### The problem it was actually solving Before MCP, every AI model that needed to talk to an external tool or data source needed its own bespoke integration for that tool. If you have N models and M tools, that’s N × M custom integrations to build and maintain, since every new model needs a fresh build against every tool it wants to use, and every new tool needs a fresh build against every model that wants to use it. It’s the classic “everyone invents their own adaptor” problem, and it scales badly: add one more model or one more tool and the number of integrations you owe doesn’t grow by one, it grows by however many models or tools already exist on the other side. MCP collapses that into N + M. A model implements MCP once; a tool implements MCP once; from then on, any MCP-speaking model can talk to any MCP-speaking tool with zero custom work in between. That’s the whole USB-C comparison: different manufacturers, different devices, one shared interface instead of one cable per pairing. ### What foundations actually do here Handing a protocol to a foundation isn’t a branding exercise. It changes who gets to decide what MCP becomes next. Under the Linux Foundation, the Agentic AI Foundation runs an open governance process, with proposals, working groups and public specification drafts, rather than one vendor unilaterally deciding the roadmap. That’s what let Google, Microsoft and AWS ship input into the July 2026 specification (2026–07–28) alongside Anthropic: a shift to a stateless architecture, an MCP Apps extension for server-rendered UIs, a Tasks extension for long-running work, authorisation aligned more closely with OAuth/OpenID Connect, and a formal deprecation policy so future changes don’t break what’s already deployed. A foundation is what makes a spec “trustworthy enough to build a business on” instead of “trustworthy enough for a hobby project.” ### What the ecosystem actually looks like MCP has three moving parts: clients (the AI application, like Claude Desktop, an IDE, or a custom agent) that request context and tools; servers (thin adaptors in front of a database, SaaS tool or internal system) that expose what’s available; and the protocol itself, the shared language that lets any client talk to any server without a bespoke integration. As of mid-2026 there are reportedly 5,800+ public MCP servers and 300+ clients. That’s the ecosystem: not one company’s product, but a marketplace of interchangeable pieces. Every arrow in that picture is the same protocol call: the client sends a tools/call (or tools/list, or resources/read) request over JSON-RPC, and the server answers in the same shape whether it's fronting a Postgres database or a Salesforce instance. That uniformity is what lets one client swap between servers, or one server serve many clients, without either side knowing anything about the other's internals. ### How fast is “fast,” really? Here’s the comparison worth sitting with. TCP/IP, the protocol the entire internet runs on, was first drafted around 1974, formally standardised in RFCs 791/793 in 1981, and only became the ARPANET’s mandatory protocol on “flag day,” 1 January 1983. That’s roughly nine years from first design to universal cutover, inside a small, closed research network. HTTP took longer to formalise (1991 to RFC 1945 in 1996, about five years) but had a comparably small starting user base. MCP went from a single-company release to multi-vendor foundation governance in 13 months, and to a mature, versioned, backward-compatible specification in 20 months, across an open, competitive, commercial market, not a government-funded research network. That speed is the story. It’s also the risk. TCP/IP and HTTP had years of small-scale, low-stakes use before they carried the world’s traffic. MCP is being asked to carry enterprise data at global scale before its governance curve has caught up with its adoption curve, which is exactly where the trouble shows up: over 30 CVEs filed against MCP implementations in early 2026 alone, a cross-tenant data leak at Asana, a path-traversal flaw at Smithery that exposed thousands of apps, and tool-poisoning attacks against open-source servers. ### The real concern isn’t the integration, it’s the opacity Most write-ups frame MCP’s challenge as “will bespoke integrations become obsolete.” That’s the smaller problem. The bigger one: once an AI agent can reach into a dozen systems through a dozen MCP servers, you often can’t fully account for what data it touched, what it retained, or what shaped its answer. Tool calls happen inside the model’s reasoning, not in a place most teams are logging or reviewing by default. You’re not just worried about whether the integration works; you’re worried about whether you can explain, after the fact, what your AI actually did with the data it saw. ### Why this matters for a PM, concretely, not abstractly Take GDPR as the simplest, most immediate example, since almost any business with EU customers already has to think about it. From a purely business angle, this is a first-mover edge hiding in plain sight: whoever architects their MCP layer with compliance built in gets to close enterprise deals faster, because “show me your AI audit trail” stops being a scary question. Right now most competitors are still bolting AI features onto products without touching this layer at all, which is a real gap. The businesses that treat MCP governance as a selling point rather than a cost centre will win the procurement conversations the others are quietly losing. The opportunity: - MCP standardises how an AI agent requests data, which also standardises where you can insert a compliance checkpoint. - A single MCP gateway in front of your CRM, HRIS or support tooling can enforce field-level data minimisation. - It can log every tool call for an audit trail. - It can apply a documented lawful basis per data field, once, centrally, instead of per integration. - Done well, this makes GDPR compliance easier to demonstrate than a patchwork of custom API integrations, because the access pattern is uniform and inspectable. The problem: - MCP itself doesn’t handle data protection, it’s a thin protocol for tools/list and tools/call, with no built-in controls against exfiltration, retention or cross-border transfer. - If your MCP server routes an EU customer record through a US-hosted server to a US-hosted model, you’ve triggered a cross-border data transfer with all the Schrems II baggage that implies. - If that server caches the payload along the way, you’ve quietly expanded your compliance exposure without writing a single line of “new” code. - From the outside, it still just looks like “the AI answered a question.” Same protocol, same feature: opportunity and liability depending entirely on how deliberately it’s architected. That’s the actual decision in front of a PM evaluating MCP: not whether to adopt it, but whether your organisation is treating the governance layer as seriously as the integration layer. --- Source: https://halukdemirhan.com/writing/aim-to-moon-day-1/ ## Aim to Moon, day 1: I launched my app (and broke it on the same day) Haluk Demirhan · 23 April 2026 · First published on Medium (https://medium.com/@halukdemirhan/aim-to-moon-day-1-i-launched-my-app-and-broke-it-on-the-same-day-1ab112c0063a) I almost messed up my launch. Not in a dramatic, startup-ending way… But enough to make early users unable to pay. Yeah. Day 1. Hey, I’m Haluk. I’m building a subscription-based mobile app as a solo founder, and I’m documenting. The goal is simple:) $10K MRR. No team. Just me. ### Why this app? I didn’t start with some genius idea.Actually, I saw something interesting: Apple started banning or limiting certain AI-generated “slide/gamma-style” apps. Most people would avoid that space. I went directly into it. Because when platforms start cleaning a category, it usually means one thing: There’s money there. ### The plan (which sounded simple) Build a slide generation app. - AI generates the content - App turns it into slides - User exports it Done, right? Not even close. ### Reality kicked in fast Generating content with AI? Easy. Turning that into structured, editable slides inside an app? Pain. I built everything in FlutterFlow because I wanted speed, not perfection. But then I hit the real problem: #### How do you structure AI output into something users can actually use? I ended up building a weird indexing system where every piece of content becomes editable text blocks. It works… But the preview and export still don’t fully match. That alone cost me about a week of just debugging and rebuilding. ### The part that almost broke me: subscriptions I knew I wanted recurring revenue from day one. So I thought: “Okay, just plug in subscriptions.” No. FlutterFlow docs are outdated. Tutorials don’t match reality. Half the internet points to things that don’t exist anymore. I did around 30 TestFlight builds just to understand what’s going on. Eventually, I realized: They moved everything to RevenueCat. No clear docs. No proper guide. Just one random blog post that saved me. After that, everything suddenly worked. ### My risky decision I didn’t do what most apps do. No free trial. No freemium. Hard paywall. You open the app → you pay. I don’t know yet if this is smart or stupid. We’ll see. ### App Store review humbled me I submitted the app thinking: “Okay, MVP is ready.” Rejected. Fair enough. Issues: - No logout - Dark mode broken Fixed them. Submitted again. Rejected again. This time the reason made no sense at first: “We can’t find your paywall.” Turns out… I never submitted my subscriptions. I thought subscriptions were separate from in-app purchases. They’re not. That mistake alone delayed everything. ### The launch (and the mistake) Finally got approved. App is live. I’m checking everything, excited… Then I realize: I accidentally deleted one of the subscription products while fixing things. Result: - Some users couldn’t see all plans - Some couldn’t purchase at all On Day 1. ### Perfect. ### Where I am right now The app works. People can use it. Some things are broken. Some things are surprisingly solid. And honestly? It finally feels like a real product, not just another side project. ### Why I’m sharing this Because most “build in public” posts are too clean. Everything sounds planned. Everything looks smooth. It’s not. It’s messy, confusing, and sometimes you spend hours on problems that shouldn’t exist. ### What’s next - Fix payment issues - Improve slide rendering - Start testing user behavior - Figure out if this can actually make money Day 1 is done. Not perfect. Not pretty. But real. If you’re also building something solo, you’ll probably recognise parts of this. I’ll keep sharing everything — wins, mistakes, all of it. Let’s see where this goes. Fallow me 🌙 --- Source: https://halukdemirhan.com/writing/from-data-driven-organisations-to-ai-driven-individuals/ ## From data-driven organisations to AI-driven individuals Haluk Demirhan · 28 January 2026 · First published on Medium (https://medium.com/@halukdemirhan/from-data-driven-organizations-to-ai-driven-individuals-7906b0207320) ### How Systems Thinking Is Quietly Reshaping Work In recent years, becoming data-driven has shifted from a competitive advantage to a baseline expectation for organizations. Companies that systematically measured user behavior, operational efficiency, and outcomes consistently outperformed those relying on intuition alone. Empirical evidence from large-scale studies supports this shift: research from Harvard Business School shows that startups engaging in structured experimentation and data-driven decision-making scale faster and attract more investment than those guided primarily by gut instinct (HBS, 2017). I previously wrote about why this transition toward data-driven thinking was almost inevitable at the organisational level. Lately, however, I’ve been reflecting on a closely related but underexplored question: what happens when the same logic is applied at the individual level? My view is that artificial intelligence is now enabling a new working model, one in which individuals can operate with a level of leverage that previously required entire teams. This is not a claim that companies will disappear or that collaboration will lose relevance. Rather, it suggests that the minimum efficient scale of work is changing. Tasks that once demanded coordination across multiple roles, analysis, content production, basic design, reporting, customer communication, can increasingly be orchestrated by a single individual using AI-based systems. In this sense, AI begins to resemble less a “tool” and more an operational layer. ### From Data as Input to AI as Infrastructure Data-driven organizations learned to treat data not as a by-product of operations, but as an active input into decision-making. Metrics became shared reference points, experimentation reduced uncertainty, and feedback loops accelerated learning. Over time, this logic reshaped how products were built, how teams aligned, and how risk was managed. AI extends this logic one step further. Rather than merely informing decisions, AI systems increasingly execute, coordinate, and adapt. Large language models, generative design tools, automated analytics, and agent-based workflows can now translate high-level intent into concrete outputs. This allows individuals to focus less on execution and more on direction. Economists Erik Brynjolfsson and Andrew McAfee have described this shift as a move toward “augmentation rather than automation,” where human judgment is amplified rather than replaced (Brynjolfsson & McAfee, The Second Machine Age). At the individual level, this augmentation compounds quickly. One person equipped with AI systems can test ideas, launch offerings, analyse feedback, and iterate at a pace that previously required a small team. ### The One-Person System, Not the One-Person Hustle I often think of this emerging model as a one-person system or, informally, a “one-person factory.” Not in the sense of doing everything manually, but in overseeing a structured system that handles repeatable and scalable work. The individual’s role shifts from execution to orchestration. Decisions revolve around setting goals, defining constraints, evaluating outputs, and deciding where human judgment is still essential. This mirrors how effective managers operate inside larger organizations, but compressed into a single actor with machine-supported leverage. From a business perspective, the implications are significant. Cost structures become lighter, decision cycles shorten, and experimentation becomes cheaper. A consultant, creator, or founder can explore opportunities without committing to a full organizational setup. Research from McKinsey suggests that AI-enabled workflows can reduce time spent on routine cognitive tasks by 30–40%, effectively expanding individual capacity without proportional increases in cost (McKinsey Global Institute, 2023). ### Creative and Experiential Work at Smaller Scales This logic is not limited to analytical or operational domains. Creative industries may feel its impact just as strongly. Advances in generative visuals, sound synthesis, and real-time adaptation enable small teams, or even individuals, to design experiences that once required large production crews. What changes here is not merely efficiency, but control and speed. Smaller units can iterate faster, maintain creative coherence, and respond dynamically to audiences. The value shifts from scale for its own sake to adaptability and precision. Stanford’s Human-Centered AI Institute notes that as generative systems mature, creative direction and contextual judgment become the primary differentiators, areas where humans still outperform machines when paired effectively with AI (Stanford HAI Report, 2024). ### Staying Small by Design This is not a universal trajectory. Many organizations will continue to benefit from deep specialization, large teams, and complex structures. However, alongside them, I expect to see a growing class of professionals who stay small by design, not due to lack of ambition, but because technology allows them to operate efficiently without expanding headcount. Historically, scaling output required scaling people. AI disrupts that assumption. Output, reach, and experimentation can now grow independently of organizational size. This decoupling has long-term implications for entrepreneurship, consulting, and creative work. ### Forward Projections: What Likely Comes Next Looking ahead, several trends appear plausible rather than speculative. First, AI-assisted work is likely to become a baseline expectation, much as data literacy did over the past decade. Individuals who cannot design, manage, or critically engage with AI-supported systems may face constraints similar to organizations that once ignored data altogether. Alongside this shift, personal operational stacks are likely to emerge. Custom combinations of AI tools, workflows, and data pipelines , tailored to individual goals, will increasingly function as a form of competitive advantage. These systems will be difficult to replicate without hands-on experimentation and accumulated judgment. As execution becomes cheaper, the true bottleneck moves upstream. Strategic value will concentrate around judgment: deciding what to build, why it matters, and when human involvement is essential. In an environment of abundant capability, clarity of intent becomes the scarce resource. For me, this is not about forecasting a radical future. It is about recognizing a gradual shift already underway. Just as being data-driven became a baseline organisational requirement, AI-assisted systems thinking is likely to become a baseline capability for individuals. Those who learn to design, govern, and evolve these systems early are likely to gain not only efficiency, but strategic freedom, over how they work, what they build, and the scale at which they choose to operate. ### References & Further Reading - Brynjolfsson, E., & McAfee, A. (2014). The Second Machine Age. W. W. Norton. - Harvard Business School. (2017). Experimentation and Startup Performance. - McKinsey Global Institute. (2023). The Economic Potential of Generative AI. - Stanford Human-Centered AI Institute. (2024). AI Index Report. - Ries, E. (2011). The Lean Startup. Crown Publishing. - OpenAI. (2023). GPT-4 Technical Report. --- Source: https://halukdemirhan.com/writing/why-every-startup-project-must-be-data-driven/ ## Why every startup project must be data-driven Haluk Demirhan · 21 May 2025 · First published on Medium (https://medium.com/@halukdemirhan/why-every-startup-project-must-be-data-driven-9121d72849a3) In the age of lean startups and agile teams, building on gut instinct alone is a recipe for chaos. Data is critical for making fast, accurate decisions based on facts, not just experience and intuition. Every time a project team skips the numbers, it takes a blind leap. Instead, imagine your project as a rocket ship: data is the dashboard and fuel-gauge that keep you on course. When Netflix, Google, or Amazon tweak even a pixel on their app, they measure the outcome. This “data-first” mindset turns uncertainty into clarity. In fact, Harvard researchers found that startups running real experiments (like A/B tests) “scale more quickly, launch more products, and attract more venture capital” than those relying on hunches (library.hbs.edu (https://www.library.hbs.edu/working-knowledge/is-ab-testing-effective-evidence-from-35000-startups).) ### The Power of Data Over Gut Feelings Think of a startup founder confronted by two possible features. Relying on a “gut feeling” might seem faster, but data wins every time. When questions arise — “Should we build this feature? Will users like it?” — data provides answers. By defining clear metrics (user engagement, conversion rate, load time), teams turn debates into concrete analysis. For example, one job-recruiting company made data a core principle: “Data is critical for making fast, accurate decisions based on facts, not just experience and intuition,” as its leaders put it (techtarget.com (https://www.techtarget.com/searchbusinessanalytics/feature/Data-driven-decision-making-case-study-Indeed).) They didn’t guess which features might work; they looked at the evidence. Using data does more than validate ideas; it speeds up learning. If an experiment fails, numbers show why, so you can pivot or refine quickly. Hunches hide mistakes until it’s too late. Lean startup pioneer Eric Ries calls this “validated learning.” By testing assumptions with real user data and iterating, teams avoid wasting time. In practice, this means running quick A/B tests on new features, measuring results, and moving on if something doesn’t work. In fact, a large HBS study of 35,000 startups confirmed that those using A/B testing (a quintessential data-driven tactic) literally grow faster and earn more investor interest than others (library.hbs.edu (https://www.library.hbs.edu/working-knowledge/is-ab-testing-effective-evidence-from-35000-startups).) In short, data turns “I think” into “I know.” ### Boosting Efficiency and Reducing Risk Data doesn’t just answer questions — it makes project teams smarter and faster. By tracking simple execution-level metrics (like cycle time, velocity, or defect rate), a team knows exactly how work is flowing. If bugs are rising or sprints are slipping, the numbers light the alarm bells immediately. This drastically cuts wasted effort: instead of blindly guessing where problems are, data pinpoints them. Teams can course-correct mid-stream, reducing costly rework. Moreover, data-driven monitoring helps manage risks. Imagine a mobile app build that unexpectedly slows down the development pipeline. Spotify’s engineers faced that: they rolled out new app versions slowly and vigilantly monitored crashes. By “putting data first” in their DevOps processes, Spotify dramatically improved decision-making and productivity (engineering.atspotify.com (https://engineering.atspotify.com/2020/07/leveraging-mobile-infrastructure-with-data-driven-decisions/).) In practical terms, this meant collecting build and performance metrics every day so they could fix issues before they hit users. For your project, it might mean automated tests, performance dashboards, or bug-frequency charts. In all cases, you catch a problem when it’s small — not when it’s a full-blown crisis. On the efficiency side, data shines a light on bottlenecks. Teams that chart their throughput and backlog can see exactly where work stalls. They can set smarter priorities and pull work in the right order. The result? Faster delivery with fewer surprises. In one study, 88% of business leaders said data analytics delivered measurable business value (techtarget.com (https://www.techtarget.com/searchbusinessanalytics/feature/Data-driven-decision-making-case-study-Indeed).) By contrast, purely instinct-driven projects often slip deadlines, waste resources, and launch with poor ROI. ### Aligning Teams Around Facts One of data’s biggest hidden superpowers is alignment. When everyone on the team — from developers and designers to sales and marketing — looks at the same metrics, they speak a common language. Goals become quantifiable. For example, a product manager might say “We need to reduce onboarding time by 20%,” and engineers can track that with data. This shared clarity keeps cross-functional teams rowing together rather than apart. In a data-driven organization, every team member has the information needed to act. For instance, career platform Indeed became “data-driven” by giving all employees the tools and data to guide their work (techtarget.com (https://www.techtarget.com/searchbusinessanalytics/feature/Data-driven-decision-making-case-study-Indeed)). They built dashboards and metrics so that “employees at all levels have the high-quality data… they need to turn raw data into… actionable information,” letting them “determine the best course of action to achieve business goals” (techtarget.com (https://www.techtarget.com/searchbusinessanalytics/feature/Data-driven-decision-making-case-study-Indeed).) In practice, that meant engineers and marketers saw the same dashboards and knew exactly how a code change or marketing campaign affected user signups. ### Success Stories: Data in Action The best inspiration is real-world success. - Curative (Healthcare startup) — When COVID-19 testing demand dropped, Curative pivoted to become a next-generation health insurance provider. They didn’t guess how to capture customers — they listened to data. By analyzing user behavior and testing new designs, Curative boosted its conversion rate by 22% (mouseflow.com (https://mouseflow.com/customers/curative-case-study/).) Paying attention to what people actually did (not what they thought they’d do) turned confusion into clarity, and saved the company from a dead end. - Spotify (Tech scale-up) — Spotify’s R&D teams adopted a “data-first” culture. In one case, their mobile infrastructure group tracked key performance metrics for every app release. The result: dramatic improvements in team decision-making and productivity (engineering.atspotify.com (https://engineering.atspotify.com/2020/07/leveraging-mobile-infrastructure-with-data-driven-decisions/).) Spotify engineers could see in real time whether a change sped up app load time or introduced bugs, and adjust immediately. This relentless measurement meant they spent less time on guesswork and more time on innovation. - General Tech Industry (Agile & A/B) — Across Silicon Valley, companies run thousands of small experiments every day. Netflix, Google, and Facebook famously test everything from UI tweaks to new features on segments of users before rolling out changes. This culture of experimentation has been key to their growth. As one data scientist quipped, better to test and fail fast than to invest in a feature nobody wants. - Harvard Study (Startup Growth) — The evidence is compelling: an academic study found that startups embracing experimentation “scale more quickly” and launch more products than others (library.hbs.edu (https://www.library.hbs.edu/working-knowledge/is-ab-testing-effective-evidence-from-35000-startups).) In other words, data-driven startups hit higher gear. Conversely, companies that ignore analytics tend to “flame out faster,” because bad ideas are clung to too long instead of being proven (or disproven) early (library.hbs.edu (https://www.library.hbs.edu/working-knowledge/is-ab-testing-effective-evidence-from-35000-startups).) These examples share a theme: teams defined clear metrics, gathered data continuously, and let the results decide the next move. When ideas flop, they pivot quickly. When things work, they double down. - Indeed (Recruiting tech) — To improve their product, Indeed’s data team created a “time-to-hire” index that tracks every step of the hiring process. With this metric, Indeed’s teams could “make faster and better decisions” on which features to build, because they could see exactly how changes affected hiring speed (techtarget.com (https://www.techtarget.com/searchbusinessanalytics/feature/Data-driven-decision-making-case-study-Indeed).) (For instance, if a new UI component sped up applications, the data made it obvious. If not, they iterated.) This turned every decision into an experiment with feedback. ### How to Start: Build a Data-Driven Practice Making your project data-driven doesn’t require massive budgets or data scientists on every corner. Start with these steps: - Define Key Metrics. What matters most for your project? It might be user signups per week, page load time, error rates, or something unique to your product. Write down 2–3 leading indicators you want to improve, and 1–2 lagging indicators (e.g. revenue, retention). - Instrument and Track. Set up the simplest tools you can. Even an Excel sheet or a shared dashboard (JIRA reports, Google Analytics, etc.) can capture basic data. The goal is visibility: make progress and issues visible to everyone. - Experiment and Iterate. Use A/B tests or small pilot releases to try changes. Measure the outcome. Did conversion rate climb? Did bug count drop? If yes, roll it out; if not, iterate or scrap it. As Harvard’s study found, this cycle of experiment — learn — adapt is what separates winners from flops (library.hbs.edu (https://www.library.hbs.edu/working-knowledge/is-ab-testing-effective-evidence-from-35000-startups).) - Share Transparently. Keep metrics visible — via charts, dashboards, or short stand-up reports. Celebrate gains (e.g. “We shaved 10% off load time!”) and learn from failures (“This tweak didn’t help conversion, so we’ll try a different angle.”). Transparency builds trust: everyone sees how their work moves the needle. Data-driven execution also means making sure the entire team buys in. Encourage a culture of curiosity: ask “What does the data say?” at every decision point. Train everyone to be comfortable with numbers, not just opinions. Over time, this becomes second nature: building products on evidence, not myths. ### Call to Action: Let Data Be Your North Star Every startup project faces uncertainty — but you don’t have to navigate it blindly. By anchoring execution in data, you turn wild guesses into calculated risks. Measure what matters, run experiments, and align your team around facts. Today, pick one metric that really counts for your project and start tracking it. Run a quick test of your next feature idea instead of betting on a hunch. Make data collection part of your daily ritual (even a 10-minute end-of-day report can work wonders). When you “build with data,” you empower your team to make smarter choices. You’ll spot problems early, seize opportunities quickly, and all move forward together. Make data your project’s compass — and watch your startup soar. Insights are drawn from industry case studies and research, including Spotify’s data-driven infrastructure efforts (engineering.atspotify.com (https://engineering.atspotify.com/2020/07/leveraging-mobile-infrastructure-with-data-driven-decisions/)), Harvard’s analysis of 35,000 startups (library.hbs.edu (https://www.library.hbs.edu/working-knowledge/is-ab-testing-effective-evidence-from-35000-startups)), Indeed’s data culture (techtarget.com (https://www.techtarget.com/searchbusinessanalytics/feature/Data-driven-decision-making-case-study-Indeed)techtarget.com (https://www.techtarget.com/searchbusinessanalytics/feature/Data-driven-decision-making-case-study-Indeed)), and a Curative case study showing a 22% conversion lift from analytics (mouseflow.com (https://mouseflow.com/customers/curative-case-study/)), among others. Each underscores a simple truth: data-driven execution yields real, measurable success. Let’s make it yours.