# Soon nobody will compare three webshops [Home](https://3bird.nl/)/Soon nobody will compare three webshops # Soon nobody will compare three webshops This is how someone buys a water filter today. Search, open three webshops, skim the reviews, work out whether that model actually fits their jug, compare prices, add up the shipping, and finally order from the shop that was slightly cheaper or looked slightly more trustworthy. This is how it will go. “Order a new filter that fits my Brita, no more than thirty euros, delivered tomorrow.” The assistant searches, checks the fit, weighs price against delivery time, and pays. The customer sees one proposal and says yes. Something gets sold either way. The difference is who does the choosing, and what they base it on. ## This is no longer a prediction IDC researched it this summer together with WooCommerce, and the numbers are not subtle. Among Fortune 2000 companies, agent adoption grows tenfold heading into 2027. IDC expects roughly five hundred billion dollars of digital spending to shift through agents by 2030. And the line that matters most to a shop owner: merchants who are not prepared stand to lose around a quarter of their addressable market. A quarter. Not because your product is worse or your price higher, but because you were not readable at the moment the choice was made. ## What an agent sees of your shop Almost nothing you put into it. Your photography, your design, your trust badges, your notice that only three are left in stock, your carefully written brand story: an agent does nothing with any of it. It reads your structured data. If it is not in there, it does not exist. Where shops fall down in practice: - **The price is not readable in the page.** It sits in an image, or only appears after JavaScript has loaded it. - **The product description is sales copy.** “Perfect for any kitchen” tells an agent nothing. Dimensions, materials and compatibility do. - **Compatibility is missing.** Exactly the question the customer asked, and exactly what is written down nowhere. - **Stock status is vague.** “Order before 11pm on working days” is enough for a human and useless to a machine. - **Category pages are bare grids.** No text explaining what to look for, so nothing to compare against. ## The protocols, and why you should not wait for them The standards that let agents actually buy are being built right now. Three names keep coming up. **UCP**, the Universal Commerce Protocol, comes from Google and Shopify, with Etsy, Walmart, Target and twenty-odd others behind it. It covers the path from discovery to cart, and since 17 June 2026 you can switch it on yourself through Shopify. **ACP**, from OpenAI and Stripe, handles checkout inside the AI surface itself. And there sits the most instructive warning in this whole story: OpenAI’s own Instant Checkout, the flagship product built on that protocol, shut down in March 2026 after about five months of disappointing sales. The spec lives on. The application did not. **AP2**, the Agent Payments Protocol, cryptographically proves the customer really authorised the purchase. Google started it and handed it to the FIDO Alliance in April 2026, with sixty-plus organisations behind it. These are not competitors. They sit at different layers of the same transaction, and a single purchase can use all three. That still leaves you unable to know which one matters in three years, and the Instant Checkout story shows what happens when you tie yourself to one horse. Happily, you do not have to. Underneath all three lies the same layer, and that one does not change: your product data has to be correct, structured and retrievable from outside. That work is never wasted, whichever protocol wins. ## What you can do this month on WordPress Concrete, and most of it takes hours rather than weeks. - **Check your product schema.** Yoast and Rank Math lay a foundation, but they do not fill in your own product attributes. Run a few product pages through Google’s Rich Results Test and look at what actually comes out. - **Turn on llms.txt.** Yoast SEO generates it automatically from version 22.0, Rank Math from 1.4.0. It is a plain text file on your domain explaining what you sell and where the important pages are. - **Rewrite product copy for machines.** Specifications as a list rather than prose. Compatibility stated explicitly, including what does not fit. That last part feels like arguing against your own sale, but an agent that cannot confirm a fit simply will not propose the product. - **Give category pages some text.** What to look for, which sizes exist, who each option suits. - **Put an FAQ block on product pages** with the questions your support desk already gets. - **Measure it.** Split out traffic from ChatGPT, Perplexity and Gemini in GA4 so you can see whether anything is moving. ## Why this sits differently for WordPress shops In the same IDC research, 65 percent of digital leaders named the rigidity of their platform as the biggest barrier. Closed systems where capability is gated behind a higher subscription tier, and where you cannot get at your own data. On WooCommerce you do not have that problem. You own your data, you can add any field you need, and no vendor is putting an API behind a pricier plan. Right now that is a genuine advantage. The flip side holds just as firmly: nobody is going to do it for you either. Shopify turns UCP on for its entire customer base with one switch. On your shop it happens when somebody sets it up. ## Why not next year Because you will not watch it happen. When search traffic falls you see a chart dip and you go find out why. Here there is no chart. Nothing tells you an assistant considered your filter three times and dropped it three times because nowhere did it say whether the thing fits. Your revenue just drifts slowly toward competitors who were readable, and by the time you notice you are a year behind. And this work is cheap while it is small. It gets expensive the moment it has to happen under pressure. ## Want to know where you stand? In forty-five minutes we will fetch a few of your product pages the way an agent does and show you what is readable and what is not. No story about the future, just what is there now and what we would tackle first. [Book a 45-minute call](https://calendly.com/3-bird/45min) or email [contact@3bird.nl](mailto:contact@3bird.nl). ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/Soon nobody will search for the cheapest flight # Soon nobody will search for the cheapest flight This is how you book a flight today. You open Skyscanner or Google Flights, put in some dates, scroll past twenty options, open four tabs, weigh layover times against baggage fees, decide you would actually rather fly from a different airport, and half an hour later you book something you hope was the best choice. This is how it will go. You tell your assistant: book me a flight to Lisbon on Tuesday morning, no connections, landing before ten, use my Flying Blue number. Twenty seconds later you get one proposal with the reasoning attached. You say yes. That difference looks small. It is the biggest thing happening to websites in the next few years. ## What actually shifts In the first case, you do the comparing. The website has to convince you, so it is built to convince you: good photography, reassuring design, a button that stands out, a note that only two seats are left. In the second case an agent does the comparing, and it works differently. It acts as an orchestrator: it spins up specialised sub-agents to solve individual pieces, say finding the best hotel, checking it against your loyalty points and verifying the cancellation policy, then combines those results into a single answer. All you do is confirm. That agent is immune to your design. It does not see a scarcity banner and does not feel urgency. It wants to know what it costs, what the terms are, whether it is available, and whether it can complete the booking. ## This is not about travel The flight analogy is useful because everyone recognises it, but the mechanism is not specific to travel. Anywhere someone currently compares options before choosing, this is coming. Insurance. Suppliers. Professional services. Asking three companies for a quote. When your customer tells an assistant “find three firms that can do this and request quotes”, the question is no longer whether your website looks good. The question is whether you make the list of three. ## The uncomfortable part Your website was almost certainly built to win a click. Twenty years of SEO practice is about ranking high enough that someone clicks, and then persuading that visitor once they arrive. If there is no click, that model stops working. The awkward bit is that you will not watch it happen. When search traffic drops you see the numbers fall and you go investigate. With agents there is no signal. There is no line in your analytics saying an assistant considered you three times and ruled you out three times because your pricing was not readable anywhere. You simply notice nothing, and that is exactly the problem. ## What an agent needs The practical translation is less exotic than it sounds. Agents need three things, and you probably have two of them half sorted. **Structured data.** Schema.org has been the standard for years for telling a machine what is on your page: this is a product, this is the price, this is availability, this is a service with these properties. For search engines that was useful. For agents it becomes the foundation. **Current information.** A 2024 price list inside a PDF is annoying for a human and worthless to an agent. Anything you want taken into account has to be correct and machine-readable. **A way to do something, not just read something.** This is the big one. In travel it is now said plainly that companies have to become API companies. That applies far beyond travel. If an agent can only read at your site while it can book, request or reserve at your competitor’s, you know how that ends. ## The standards taking shape Several parties are building the plumbing right now. MCP servers for search and shopping. WebMCP and Cloudflare Markdown as protocols for agent browsers. Google is working on UCP, a universal commerce protocol, which has not been adapted to travel yet but almost certainly will be. And underneath all of it sits plain Schema.org. Nobody knows which of these is the standard in three years. That is not a reason to wait, because there is a layer underneath that does not change: your data has to be correct, structured and retrievable from outside. That work is never wasted money, whichever protocol wins. ## What we would do now No large programme, no bet on a single technology: - **Get your structured data right.** It costs little, already helps with ordinary search engines today, and is the base for everything that follows. - **Look at what an agent actually sees on your site.** Not what you see in your browser. Fetch your own pages the way a machine does and check whether prices, terms and availability are in there, or only inside an image or a script. - **Make your key data retrievable.** Start small: one endpoint with your services, rates or availability. You do not have to open up your whole business to count. - **Experiment with one agent protocol.** Stand up an MCP server for a bounded part of your offering and see what happens. That is a week of work, not a quarterly project. ## Why now and not next year Because this work is cheap while it is small, and expensive the moment you have to do it under pressure because a competitor already has. And because falling behind here is invisible. You get no warning. You see no decline. You just get proposed less and less often, by assistants your customers have come to trust, and by the time it shows up in revenue you are a year behind. ## Where do you stand? In forty-five minutes we will look at your site the way an agent would and tell you what is readable and what is not. No pitch about the future, just what is there now and what we would tackle first. [Book a 45-minute call](https://calendly.com/3-bird/45min) or email [contact@3bird.nl](mailto:contact@3bird.nl). ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/Which AI is actually running in your company? # Which AI is actually running in your company? Ask any CTO which AI tools are running in their organisation and you get a list. Then ask five developers what they used this week, and you get a longer list. The gap between those two is what an AI audit is about. At most companies, AI did not arrive through a decision. It arrived through people. Someone took out a Cursor subscription because it helped. Marketing started generating copy. Somebody built an agent that reads the shared mailbox and turns it into tickets. Each of those was a sensible call. Together they add up to an infrastructure nobody designed and nobody documented. ## What you map first An audit starts boring, with an inventory. Three questions, and the answers usually disappoint. **Which tools are running, and what data leaves through them?** Not just the ones on the invoice. Also the free accounts, the browser extensions and the personal subscriptions people use for work. For each one you want to know what goes out and whether your contracts allow it. **Which code was written by AI, and what happened to it?** In most repositories you cannot tell. There is no marker, no separate review trail, no distinction between code a senior worked through and code that went from a model straight into the main branch. **Which keys do your agents hold, and what do those keys allow?** This is the question that most often produces silence. An agent that processes invoices has a token somewhere. It was created once, probably with wider permissions than it needed, and almost certainly without an expiry date. ## Where it goes wrong in practice The patterns we run into are strikingly consistent. - **Keys without a lifecycle.** Human accounts have an onboarding and an offboarding process. Agents rarely do. No rotation, no expiry, and nobody noticing that a token from an abandoned experiment still works. - **Over-permissioned service accounts.** During development you give an agent admin because otherwise you keep hitting permission errors. That almost never gets rolled back. - **Exposed MCP endpoints.** More companies are standing up an MCP server for their own systems so AI clients can reach them. That is a writable API on your production environment. It deserves the same scrutiny as any other writable API, and often does not get it. - **Prompt injection through content.** If your agent reads email, documents or web pages, it is reading text somebody else wrote. Put an instruction in there, and an agent without a clear separation between data and commands may simply carry it out. - **No view of dependencies.** Without a current list of what is inside your software you do not know what you are pulling in. That was already a problem. With models that regularly reference packages which do not exist, it has not got smaller. ## Three layers, in order of urgency The Cloud Security Alliance uses a split that works well in practice, because it separates what you do this week from what is a programme. **Immediate.** Inventory every AI tool in use. Scan your repositories for keys and passwords left behind. Check your dependencies against a current list. This is days of work, not months, and it almost always turns something up. **Short term.** Move security testing to the moment code is created, rather than waiting for the pipeline. Write down where AI assistance is not used without review: authentication, authorisation, cryptography and input validation are the obvious four. Assess the platforms your team uses against your own vendor requirements. **Structural.** Give agents the same lifecycle as employees, including rotation and revocation. Record in your dependency list which parts were AI-generated. And put governance in writing before somebody else does it for you, because the European AI Act is phasing in, and for nearly every obligation the first practical step is the same: knowing what you have. ## What you can check yourself today You do not need us to run the first three checks. They cost an afternoon and usually tell you enough to know how bad it is. **Scan your repositories for leftover keys.** Tools like gitleaks or trufflehog walk your entire git history, not just the current files. That distinction matters: a key removed last year is still sitting in the history, and a repository that was ever public has been public forever. **List your tokens and look at when they were created.** GitHub, your cloud provider and your main SaaS vendors will all tell you. Anything older than a year without a clear owner is suspect. Anything without an expiry date is a debt. **Check what your service accounts are actually allowed to do.** Not what the documentation claims, but what the permissions say. The question to ask yourself is simple: if this account falls into the wrong hands tomorrow, how far does someone get? If none of that turns anything up, you are in better shape than most. If it does, you now know where to start. ## Why a report is not enough The trouble with audits is that they are a snapshot. You get a document, you fix the worst of it, and three months later the situation has moved again. Not through negligence, but because this field simply moves faster than your audit cycle. So we do not hand over a report and shake hands. We put AI-Sitters in place: senior developers who work alongside your team, review AI-generated code before it reaches the main branch, and keep an eye on the permissions your agents accumulate over time. The AI can go as fast as it likes. There is just someone sitting next to it who knows where this breaks. ## Starting at the start If you read the above and thought “no idea how that stands with us” at more than one point, that is your answer. It is not embarrassing. It is where nearly everyone is right now. [Book a 45-minute call](https://calendly.com/3-bird/45min) and we will walk through the three inventory questions together. After that you will know whether a full audit is worth it, or whether an afternoon of tidying up will do. Email works too: [contact@3bird.nl](mailto:contact@3bird.nl). ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/Your prototype works. That’s not the same as finished. # Your prototype works. That’s not the same as finished. It almost always goes the same way. Someone spends a few evenings building something with Lovable, Bolt, Cursor or plain ChatGPT. It works. The demo runs, the first customer is enthusiastic, and then comes the sentence that changes everything: “Can we go live with this next month?” At that moment the question shifts from “does it work?” to “will it hold?”. Those are two very different questions. ## What “it works” actually means A prototype proves one thing: that the happy path works. One user, doing exactly what you expect, with clean input, at a quiet moment, with nobody trying to break anything. Production is everything else. A hundred users at once. Someone pasting an emoji into a phone number field. A payment that fails halfway through. A bot that finds your form and hits it ten thousand times an hour. An employee who clicks the wrong button and wants you to undo it. None of that is a failing of the AI that wrote your code. It simply isn’t what you asked for. You asked for something that works, and that is what you got. ## The numbers are no longer vague Until recently this was mostly developer intuition. It isn’t anymore. Veracode tested over a hundred language models on security-sensitive coding tasks. In 45 percent of cases the generated code contained a vulnerability from the OWASP Top 10, the standard list of most common security flaws. For cross-site scripting it rose to 86 percent. More telling than the number itself: between 2025 and early 2026 it did not improve, even as the same models got measurably better at every other coding benchmark. Security firm Escape.tech scanned fourteen hundred applications built on vibe-coding platforms. They found over two thousand critical vulnerabilities, more than four hundred leaked passwords and keys, and a hundred and seventy-five cases of personal data sitting in the open: medical records, financial details, credentials. At a Fortune 50 company, Apiiro measured what happens when you scale this up. Developers working with AI assistance shipped three to four times as much code. Monthly security findings went from around a thousand to more than ten thousand. The most serious category, paths that let someone grant themselves more access than they should have, grew by 322 percent. That last figure is the interesting one. This isn’t about sloppy typos. It’s about structure, about decisions on how the system fits together, and those don’t get fixed with a quick patch. ## Why this happens, and why it makes sense A language model writing code optimises for code that runs. Not for code that holds up when someone means it harm. It has no picture of your threat model, doesn’t know your GDPR obligations, and can’t tell which of your data is sensitive. There’s a wrinkle on top of that which surprises most people. Roughly one in five times, AI-generated code refers to a software package that doesn’t exist. The model invents a plausible name. Attackers have started exploiting this: they register those invented names in advance, with malicious code inside, and wait for someone to install them. There’s a word for it now: slopsquatting. And the built-in code review those platforms offer? In practice it regularly misses the serious problems, like SQL injection, while dutifully reporting that your indentation is inconsistent. ## What sits between demo and production When we take over a vibe-coded project, this is roughly the list we work through. Not exciting, but it is the difference between a demo and a business asset. - **Secrets and keys.** API keys sit in the source code remarkably often, and not rarely in a public repository too. - **Access and permissions.** Who may see what, who may change what, and is that enforced on the server or merely hidden in the interface? - **Input validation.** Everything arriving from outside is suspect until proven otherwise. - **Dependencies.** Does every package actually exist, does it come from who you think, and is anyone maintaining it? - **Errors and logging.** What happens when something breaks, and can you reconstruct afterwards what went wrong? - **Backups and recovery.** Not whether a backup exists, but whether you have ever restored one. - **Deployment.** A manual step nobody can describe precisely is an outage waiting to happen. The good news: this is bounded work. Usually weeks, not months. And we almost never throw the prototype away. The functionality is often fine. The foundation underneath isn’t. ## Not less AI, but supervision over it Please don’t read this as an argument to stop building with AI. That speed is real, and going back would be daft. What matters is that speed without supervision hands you something that looks finished and isn’t. That’s why we put AI-Sitters on it: senior developers who direct, review and refine AI-generated code with the discipline production software demands. The AI does the typing. A human who has seen this before decides whether it ships. It costs you no pace. It does decide whether you end up with something that impresses in a demo, or something your customers can rely on. ## Sound familiar? Do you have something running that works, but you’re not quite ready to let real customers near it? A forty-five minute conversation is usually enough to establish what’s needed. We look it over, tell you honestly what we see, and if it’s already in good shape you’ll hear that too. [Book a free 45-minute call](https://calendly.com/3-bird/45min), or email [contact@3bird.nl](mailto:contact@3bird.nl). ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/Scaling Engineering Teams: Hiring, Onboarding, and Culture # Scaling Engineering Teams: Hiring, Onboarding, and Culture ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/React vs .NET in 2025: Choosing the Right Stack for Your Next Project # React vs .NET in 2025: Choosing the Right Stack for Your Next Project Stack selection is one of the most consequential decisions a development team makes — and one of the most frequently over-complicated. Every year the landscape shifts slightly, but the underlying decision framework for European commercial software remains remarkably stable. Here is how to think about the React vs. .NET question in 2025, without the hype. ## First, a Clarification React and .NET are not alternatives — they operate at different layers. React is a JavaScript library for building user interfaces. .NET is a cross-platform development framework for building backends, APIs, and services. Most modern applications use both. The real questions are: - **Frontend**: React, Vue, Angular, or something else? - **Backend**: .NET, Node.js, Python, Java, or Go? - **Full-stack**: What is the right pairing for your context? ## React in 2025 React remains the dominant frontend library in European commercial development. Its advantages: - Largest talent pool among JavaScript frameworks in the Netherlands and EU - Mature ecosystem (Next.js, React Query, Radix UI, Tailwind CSS) - Strong corporate backing with stable API evolution - Excellent tooling for both SPA and server-side rendering React’s disadvantages are real: JSX has a learning curve, state management choices can be overwhelming, and the ecosystem moves fast enough that senior React developers need to actively maintain their skills. **React is the right choice when** you need a rich, interactive user interface; you want access to the widest talent pool; or you’re building a product where frontend velocity is the primary constraint. ## .NET in 2025 .NET 8 and 9 have continued the framework’s transformation into a genuinely modern, cross-platform runtime. Its advantages: - Excellent performance, consistently near the top of independent benchmarks - Strong typing throughout the stack reduces runtime errors - First-class support for microservices, gRPC, and messaging architectures - Deeply familiar to the large enterprise market in the Netherlands - Strong GDPR tooling within the Microsoft/Azure ecosystem **.NET is the right choice when** you’re building for enterprise clients with existing Microsoft infrastructure; you need high-performance backend services; or you’re in a regulated industry where the Microsoft compliance story matters. ## The Common Pairing For most 3Bird clients, the optimal pairing in 2025 is **React (frontend) + .NET (backend API)**, deployed on Azure or AWS. This combination: - Maximises talent availability across Europe - Provides strong typing on both sides (TypeScript + C#) - Fits the Microsoft ecosystem that most Dutch enterprises already use - Has excellent tooling for testing, CI/CD, and compliance For startups optimising for speed and a smaller initial team, React + Node.js (TypeScript throughout) remains a strong alternative — particularly for teams that want to share code between frontend and backend. ## When Stack Doesn’t Matter as Much as You Think For most MVPs and early-stage products, the stack is less important than the team’s familiarity with it. A team that knows Django deeply will outship a team learning .NET at speed. If you have strong existing expertise, lean into it. At 3Bird, our recommendations are always contextual. We have deep expertise in React, .NET, Node.js, and Python — and we’ll be honest with you when the answer is “it doesn’t really matter, pick one and move.” The best stack is the one your team can execute on today, with a clear path to scaling it tomorrow. ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/Offshore Development Pitfalls (And How 3Bird Avoids Every One) # Offshore Development Pitfalls (And How 3Bird Avoids Every One) In 25 years of combined experience building and managing offshore development teams, the same failure modes appear with depressing regularity. They are not unique to any country or culture. They are structural problems that emerge from the way offshore engagements are typically set up. Here is the definitive list — and what actually prevents each one. ## Pitfall 1: Requirements Lost in Translation **What happens.** A client shares a requirements document or Figma file. The offshore team builds what they understood, not what the client meant. The gap only becomes visible at demo time. **How we prevent it.** A European PM runs a structured requirements workshop before any sprint begins. Requirements are written as acceptance criteria — testable statements of what “done” means — not feature descriptions. Ambiguous criteria are flagged before development starts. ## Pitfall 2: The Silent Blocker **What happens.** A developer is blocked by a missing API key, an unclear requirement, or a technical dependency. Rather than escalate, they work around it — or silently wait. **How we prevent it.** Daily standups are run by the European PM, not reported via Slack. Blockers are a primary agenda item. The PM’s job is to make it psychologically safe to surface problems early — and to resolve them the same day. ## Pitfall 3: Definition of Done Drift **What happens.** Over time, the sprint definition of done degrades. Code reviews become rubber stamps. QA gates are skipped when timelines are tight. The first three sprints are excellent; sprint eight is a mess. **How we prevent it.** The definition of done is written, versioned, and reviewed in every sprint retrospective. Our PMs have authority to reject sprint completion if DoD criteria are not met — even under timeline pressure. ## Pitfall 4: Technical Debt Accumulation **What happens.** Offshore teams, under pressure to deliver features, accumulate technical debt silently. The client only discovers this when the system becomes too expensive to maintain or extend. **How we prevent it.** Our fractional CTOs conduct quarterly technical health reviews. A technical debt register is maintained and shared with the client. A minimum of 20% of sprint capacity is reserved for debt reduction on engagements longer than three months. ## Pitfall 5: Key Person Dependency **What happens.** One developer becomes the sole owner of a critical system component. When they leave or rotate, knowledge walks out the door. **How we prevent it.** Documentation is a sprint deliverable, not an afterthought. All significant components require at least two engineers to have worked on them within a quarter. Architecture Decision Records capture the reasoning behind key decisions. ## Pitfall 6: Timezone Friction **What happens.** The 4–5 hour timezone difference between Europe and South/Southeast Asia means that questions asked in the afternoon Amsterdam time don’t get answered until the next day. Over months, this compounds into significant lost velocity. **How we prevent it.** Our Nepal-based teams overlap Amsterdam business hours from 09:00–13:00 CET. The European PM is available during full Amsterdam business hours. Critical decisions are never left to async. Every pitfall on this list is avoidable. None of them are inevitable consequences of offshore development. They are consequences of offshore development without investment in process and oversight. That investment is what 3Bird is. ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/Why AI-Generated Code Still Needs Human QA (And Always Will) # Why AI-Generated Code Still Needs Human QA (And Always Will) Every few months, a new benchmark appears showing AI models achieving near-human performance on coding challenges. Every few weeks, a developer posts about shipping a feature entirely with AI assistance. The narrative of “AI replacing developers” has become a recurring theme. It is also, at present, wrong — and dangerously so for anyone building production systems. ## What AI Is Excellent At To be credible about AI’s limitations, we should be honest about its genuine strengths: - Generating boilerplate and scaffolding at high speed - Translating well-specified requirements into working code - Refactoring isolated functions with clear inputs and outputs - Writing documentation from existing code - Generating test cases for known-good requirements For these tasks, AI coding tools are genuinely transformative. A good AI-Sitter can move 3–10× faster than traditional development on these categories of work. ## What AI Consistently Gets Wrong **Security vulnerabilities.** AI models are trained on the internet, which includes a lot of insecure code. SQL injection, XSS, CSRF, insecure direct object references, and hardcoded secrets appear in AI-generated code with uncomfortable frequency. Security review is not optional. **Edge cases in business logic.** AI generates code that satisfies the stated requirements. It does not generate code that handles the requirements you forgot to state. A human reviewer who understands the business domain catches these gaps; AI does not. **Architectural coherence.** AI generates at the file or function level. It does not maintain a model of the entire system. The result is code that is locally correct but globally incoherent — duplicated logic, inconsistent patterns, circular dependencies that emerge only when the system is assembled. **Compliance requirements.** GDPR, accessibility, licence compatibility, and sector-specific regulations require human judgment. AI models do not reliably produce GDPR-compliant code without explicit instruction — and even with instruction, human verification is required. ## The Human QA Layer At 3Bird AI Lab, every generated module passes through: - A senior engineer review for correctness, security, and architecture - Automated test suite execution - Manual QA for business logic and user experience - A compliance check for GDPR and licence requirements This is not a box-ticking exercise. It is the reason our AI Lab output is production-quality rather than prototype-quality. The AI provides the speed. The human layer provides the quality. Neither replaces the other. Both are required — and any product team that skips the human layer in the name of speed will eventually pay for that decision in production. ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/When to Switch from AI Lab to Dedicated Developers # When to Switch from AI Lab to Dedicated Developers The 3Bird hybrid model exists because different phases of a product’s life require different kinds of development. AI Lab is optimised for velocity and exploration. 3Bird People is optimised for stability, scale, and ownership. Knowing when to switch — or combine — the two is the strategic decision that determines whether your product succeeds at scale. ## Signs You’re Ready to Transition **The product has been validated.** AI Lab is for testing hypotheses. If your MVP has paying customers, real user feedback, and a clear product direction, the phase of “building to learn” is over. The next phase requires building to last. **The codebase is growing in complexity.** AI-generated code is excellent for bootstrapping. As the system grows — more integrations, more concurrent users, more edge cases — human engineers who understand the full system become essential for maintaining quality and velocity. **You need ongoing ownership.** AI Lab engagements are project-based. When you need engineers who build institutional knowledge of your system over months and years, dedicated developers provide continuity that project-based AI-Sitters cannot. **Compliance requirements are increasing.** SOC 2, ISO 27001, PCI DSS, and sector-specific compliance frameworks require process maturity that is easier to maintain with a stable dedicated team. ## The Transition Process The 3Bird hybrid transition is managed to avoid the most common failure mode: lost context. When AI Lab hands off to 3Bird People, the process includes: - **Comprehensive handover documentation** — Architecture decisions, known limitations, technical debt register - **Architecture Decision Records (ADRs)** — Written records of why key decisions were made - **Joint sprint** — Both teams work together for one sprint, with AI-Sitters available for context questions - **Single PM continuity** — The same European PM who managed the AI Lab phase manages the People phase The result is a handover that feels like an internal team transition, not a vendor change. ## Why Not Just Stay in AI Lab? AI Lab is not designed to replace a dedicated development team indefinitely. For projects that have moved past early validation, the human oversight overhead of AI-Sitter work becomes a limiting factor — you’re spending engineering capacity on generation and review cycles when you could be spending it on new features and stability. The right tool for the right phase. That’s the principle the hybrid model is built on — and it’s why 3Bird clients who start in AI Lab and transition to People consistently report the best cost-to-velocity ratio across their full product lifecycle. ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/The Fractional CTO Model: Strategic Tech Leadership Without the Full-Time Cost # The Fractional CTO Model: Strategic Tech Leadership Without the Full-Time Cost For scale-ups between Series A and Series C, the fractional CTO has become one of the most valuable roles in the European tech ecosystem. Not every company needs a full-time CTO from day one of serious growth. But every company with more than two engineers and a production system absolutely needs C-level technical judgment. The fractional model bridges that gap. ## What a Fractional CTO Actually Does The term “fractional” sometimes creates a misconception that you’re getting a part-time junior version of a CTO. The reality is the opposite: fractional CTOs are typically more experienced than the full-time CTOs startups can afford to hire, available for the fraction of time the role actually requires at early growth stages. A fractional CTO’s typical scope: - **Architecture review** — Evaluating major technical decisions before they’re committed to - **Technical due diligence** — Preparing the codebase and team for investor review - **Team building** — Defining hiring profiles, conducting technical interviews, evaluating offshore partnerships - **Roadmap input** — Translating business objectives into technical strategy - **Incident response** — Being available when something goes wrong and the team needs senior judgment This is 10–30 hours per month of high-leverage work, not a full-time position. ## When You Need One You need a fractional CTO when: - You’re making technology decisions that will be expensive to reverse - Your team has grown beyond what your most senior engineer can effectively oversee - You’re preparing for a fundraising round that will involve technical due diligence - You’ve had quality or reliability incidents that your current team structure can’t prevent from recurring - You’re evaluating a major platform migration or offshore expansion You probably don’t need one yet when your engineering team is fewer than three people and you’re still in pure product-market fit discovery. ## The Cost Model A senior fractional CTO at 20 hours per month typically costs €3,000–6,000/month in the Netherlands. A full-time CTO in the same market costs €120,000–180,000/year in base salary alone, plus equity, benefits, and the overhead of a permanent hire. For a company where the CTO function is critical but not yet full-time, this is not a compromise — it’s the optimal allocation. ## What 3Bird Brings to the Model 3Bird’s fractional CTOs are European technologists who have operated at CTO level before joining our team. They speak the language of your investors, understand Dutch and EU regulatory requirements, and can be embedded into your team immediately — no lengthy recruitment process. For 3Bird People engagements with offshore development teams, our fractional CTOs serve as the technical bridge: they own the architecture, review offshore output, and ensure the offshore team is building toward a coherent system rather than a collection of features. ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) --- Book a free 30-minute consultation: https://calendly.com/3-bird/3bird-oscar-30-minuten-meet Email: contact@3bird.nl | Phone: +31757993038