What Y Combinator Won’t Tell You: The 27 Laws of Enterprise AI
Disclaimer: This publication is for general information only and does not constitute legal, financial, or other professional advice. The author makes no representations or warranties, express or implied, as to the accuracy, completeness, reliability, or suitability of the content, and assumes no responsibility for any loss arising from use of or reliance on it. To the fullest extent permitted by law, the author disclaims liability for any direct, indirect, incidental, or consequential damages. References to third parties (including Y Combinator) are for identification only and imply no endorsement or affiliation. No duty to update.
I just returned from deploying AI across France, Italy, and Greece, and as my memory is fresh with expensive mistakes we made, I want to share what I'm calling the 27 Laws of AI deployment. Mistakes that could have been avoided if we'd understood the patterns I'm about to describe.
Before leaving for Europe, I received many DMs from Y Combinator candidates asking: "What makes a good YC candidate?" followed by long descriptions of their AI products and "Do you think this is directionally correct?"
Most aren't directionally correct, but not for the reasons they think.
The Fatal Gap
What I've discovered is that there's a fundamental disconnect happening in the AI space, and it's causing promising startups to fail in predictable ways. Tech founders often think they understand business problems, while business leaders believe they understand technical solutions, and both assumptions are usually wrong. This gap between these worldviews is where promising companies end up going to die.
The gap between our understanding of business problems and how business people actually feel and live things "in the trenches" is what makes your product either a complete disaster or a complete life-saver. Most tech founders have never actually worked inside the companies they're trying to sell to, which means they're building solutions for an imaginary enterprise that exists only in their heads, and this disconnect becomes a sales problem and a product death sentence.
The person who has been dealing with broken processes for two years knows things you don't, and they understand which workarounds actually work, which "official" procedures get ignored, and which solutions will create more problems than they solve. If you ignore them, you do so at your peril.
After these recent deployments, I've realized there are predictable patterns to this gap. Patterns I'm organizing into 27 laws that can help you avoid the expensive education we just received.
These laws fall into five interconnected categories, like Jay Galbraith's Star Model for organizational design: how decisions really get made (Structure), what's actually motivating this project (Rewards), whether people will adopt what you build (People), if your processes can handle organizational reality (Processes), and whether you're solving the right strategic problem (Strategy).
Miss any point of this star, and your technical excellence becomes irrelevant.
Noème.AI Chronicles: When Reality Hits the Algorithm
Which place better than France, Italy, and Greece to discover these harsh truths? Milan with its architectural precision, Athens with its ancient wisdom about human nature, France with its bureaucratic elegance that would make Kafka weep.
We started projects months ago with administration personnel from a European university, later expanding to a law firm. Both turned eye-opening in discovering these 27 laws. What we found is that most software developers, machine learning experts, and AI specialists are very knowledgeable in their fields, but only 1% are aware of even one or two of these organizational rules, let alone all of them.
This unawareness exists not because of lack of intelligence, but because of a lack of certain skills that you acquire over time when dealing with complex international programs. Skills that most engineers never develop because they're too busy perfecting algorithms to pay attention to political reality.
Law 1: Map the Real Power Structure (Structure)
The organization chart is fiction, and real influence flows through informal networks, historical relationships, and the question of who controls the budget versus who controls the problem.
France taught us this lesson brutally. French universities are attached to the government with binding processes and hierarchical definition of roles that would impress a medieval court.
It was one of my first "shock" moments. In "la fonction publique" (government jobs), there are instances where you cannot make any decisions by yourself. Decision-making for your job comes from another person, and you just execute step-by-step instructions from a process document.
Some profiles are involved in decision-making and providing instructions to staff. Other profiles are purely execution: they execute decisions made and provided to them, with a concrete wall between the two functions.
The decision-makers were numb from handling decisions they couldn't delegate. The executors were numb from putting their brains on autopilot and following administrative documents. From an insider perspective, it is not a dysfunction, because the system is working as designed.
What no org chart will tell you is that the person who signs your contract often can't make the decisions that determine your success, and meanwhile, the person who actually knows how things work usually can't buy anything. If you navigate this maze wrong, you'll end up building the wrong solution for the wrong person.
In early interviews, I noticed staff showing signs of demotivation, burnout, and a lack of career perspective. For those retiring, an obvious "I won't be here in a few months, so they'll have to handle it" attitude. Government jobs offer security, but climbing the ladder requires complying with countless requirements, even presenting yourself as a candidate for elections to access some roles.
As an external consultant, you land in this peculiar environment where dynamics pull you in different directions. Your awareness of the relationship between the "donneur d'ordre" (the master who pays) and the "carriers of process history", people on the floor who will tell you what you need to know for success or failure, becomes paramount.
If you're not aware of these dynamics, you'll build and rebuild your application until your runway disappears. The boss will tell you one thing, the person on the floor will tell you another. Your first question becomes: who should I believe? The person who pays or the person who's going to use the application?
When you figure this out wrong, everything else becomes irrelevant.
Law 2: Discover What's Actually Broken (Rewards)
Companies rarely tell you their real problems, and they'll say "efficiency" when they mean "we're hemorrhaging money," or they'll talk about solving the stated problem when you should be looking for the real one.
Once we figured out the tension and inertia, we had to understand the underlying motives. Most establishments approach AI as a remedy for many different things: slowness, performance issues, customer dissatisfaction, administrative overload, P&L enhancement, freeing expert time so experts can focus on what needs expertise.
We started "taking the temperature" for these motives to see which was the main motivation. The answer was quite a shock: none!
After discussing with every interviewee assigned to explain their pain to us, we came across someone who had nothing to do with the project but gave us precious information: "The head of administration has just resigned for personal reasons, and one of the most experienced administrators handling crucial planning is retiring in three months. Everyone is under even more pressure."
There it was. We weren’t facing an efficiency problem. We were called for this project to cover an institutional knowledge walking out the door and panic about who would replace it.
When you dig deeper, you'll find the real drivers: a departing executive covering their tracks, an understaffed team buying time, or a consultant justifying their fee. Until you know what's actually motivating this project, you're building blind.
There are many situations where companies consult us when it's too late: P&L showing negative results in many areas (one was already -€20 million!), customers complaining constantly, administrative burnout across departments, experts drowning in manual tasks consuming 50% of their time. Name it.
Every enterprise has these pressure points, and if you miss them, your beautiful AI solution becomes expensive shelfware.
Business people know the value of transformation but usually take the wrong approach delivering it alone. Tech people love change and transformation but usually miss the real objective the transformation must carry.
Understanding what motivates the other party to participate in this journey is equally important for both, because this is - let me repeat - a journey.
Law 3: Choose Your Travel Companion Wisely (People)
Business should choose the right "companion of voyage." Any company can spend your money, but the right tech partner will handle your project budget as if it were theirs.
Tech people should also choose carefully, especially if you have a sense of ethics and beauty. Now you may be thinking, why should tech people care about "beauty"? We will get to that in a bit.
What I've observed is a fatal combination: business leaders who think technology is magic and tech leaders who think business is simple, and both assumptions are wrong. Success requires someone who understands that every line of code has political implications and every business process has technical constraints.
Law 4: Build for Beauty, Not Just Function (Processes)
With AI democratizing software development, you have a choice: build fast and ugly, or build right, and enterprise clients can spot the difference instantly.
We live in the era of "software abundance".
Anyone can build software, and developers can build software way faster than before. There's a saying in French: "les cordonniers sont toujours les plus mal chaussés" which translates to “shoemakers always have the worst shoes”. When you make applications for others, you forget about the ugliness of your own tools. This happens in many IT departments: they make applications for everyone while their own department runs on spreadsheets (yes, I plead guilty to this!).
With LLMs specialized in writing code, everyone can be a software developer nowadays; maybe a bad one, but still one.
Yohji Yamamoto, the Japanese anti-fashion designer who rejects mainstream haute couture, says: "If I can do something in this world, it is to change a little bit the value of beauty."
We can decide to add value to beauty, or we can be fast fashion and build ugly, unsafe software. Each of us building software has a choice, and the future depends on it.
Credit: © Paul Lovis Wagner / Greenpeace
We can succumb to making fast, cheap products that add to ugliness by ignoring security, UX design, engineering best practices, data bias, network security, GDPR compliance. Or we can educate ourselves on engineering fundamentals and build something that complies with ethics, safety, security, and protection from the beginning.
Law 5: Enterprise Isn't SMB With More Zeros (Strategy)
Your clever SMB workaround becomes an enterprise deal-killer, and if you want to build for enterprise, you need to think about it from day one, or you'll end up building it twice.
This is where many AI founders push back: "Let me build an MVP for SMEs, then adapt it to enterprise."
Bear in mind that a scaled-up product SMEs have used for years gets considered a PoC for enterprises because of missing links. When we say "PoC" in international companies, it means "throw it out and start over."
The reality is that missing audit trails, inadequate security, and no compliance framework. Any one of these kills the sale. You cannot stack garden sheds and build a skyscraper. Your self-service dashboard might work for a 10-person startup, but enterprises need foundations that can handle regulatory compliance, security audits, and integration with systems older than your programming language.
Law 6: Listen Like Revenue Depends on It (People)
Because it does, and the founder who immediately pitches after getting feedback isn't building a product. They're building a therapy session for their ego.
I interview many candidates for various roles. For technical positions, our interviews are very practical, with real-life cases involving security, data privacy, workplace conflicts, operational mistakes, pipeline errors. If you haven't worked in professional environments with complex matrix hierarchies, the team notices immediately.
Despite certifications, many candidates lack depth understanding operations in fast-paced international environments. Many boast about "knowing AI" but retreat when we ask fundamental questions. Many show evidence of software development but fail basic engineering questions.
What's increasingly noticeable is the lack of good listeners. Fewer people in tech have the ability to truly listen.
We encounter so many who are sure of what they want, what the answer is, what can be built, how AI should be used. It looks like deceiving smoke. Having confidence is great, but the main reason for existence of a service provider is being obliging and providing good service. Providing service requires you to uncenter from yourself and center attention on what users are saying, understanding layers of what they recount.
Many DMs from YC candidates demonstrate this perfectly. I provide targeted advice that could help them reflect, and I almost always see whether someone is a good listener (less than 1%) or not.
Good listeners take advice and reflect on it. Bad listeners come back immediately saying "Great advice! By the way, can you confirm if this idea is good?" Then they send paragraphs about what they're building!
Here's a test: Next time someone gives you product feedback, wait 24 hours before responding. If your first instinct is to explain why they're wrong, you're not ready to build for real customers. If your first instinct is to ask follow-up questions, you might actually succeed.
When someone provides advice, the worst thing you can do is scan it briefly, then jump back to where you wanted to go: getting confirmation. You demonstrate immaturity and lack of respect for others' time.
Ask potential customers, listen to them, ask right questions, take notes, repeat. A thousand times. The repetition will give you the answer.
The market pays and decides what it wants. Unless you're building for yourself and imaginary customers, get out of your head, make phone calls, ask questions of real people.
Law 7: Your Assumptions Are Expensive (Strategy)
Every month spent building the wrong feature costs more than a day spent validating the right one, but founders consistently choose expensive assumptions over cheap validation.
Even when understanding context, except for obvious features like close buttons, you really don't know what users want and need.
The confidence of knowing what the user wants without talking to users is a disease. If you've never worked in a specific company, never dealt with their processes, never sat alongside people from floor to C-suite, you should not assume you understand their context.
This comes from memorable mistakes. Almost every rule here comes from mistakes we had to correct or pay for.
What I've learned is that pride is an expensive business strategy, while customer knowledge is free.
Law 8: Solve the $10,000 Problem, Not the $1,000 Problem (Strategy)
The key is knowing the difference between what impresses engineers and what moves budget holders.
During academic project delivery, we listened to so much user frustration and pain that we felt close to their pain and got motivated to put ALL our knowledge on the table.
When you're bathing in technology, building almost everything seems possible. You've automated complex scenarios, seen different complex applications delivered. Add LLMs, generative AI, agents, deep learning, machine learning, orchestrated data pipelines, statistics, insights. New perspectives open for business.
For users who've worked in administration their whole lives, this sounds like science fiction. They don't believe you, and they're right. "Show me and I'll believe."
What I've realized is that impressive demos don't create paying customers, but solving critical business pain does.
This willingness to prove yourself can cause endless hours working on things you think bring value but users couldn't care less about. We learned this the hard way with AI applications.
“Give them what they need, not everything you have.” The user who said "show me and I'll believe" doesn't need to see your entire technical arsenal. They need their specific pain solved elegantly.
I believe Law 8 applies to many areas of life. Unfortunately, younger team members weren't aware of it. Now they know. It's part of our collective memory.
The Stakes Are Real
If you miss any point of the AI Reality Star, you'll join the growing pile of brilliant technical solutions that never found paying customers, but if you get it right, you'll build something that actually matters.
These are the first 8 of 27 laws we discovered across five categories. Each represents expensive lessons learned in real deployments with real consequences.
The complete framework reveals how organizational reality determines AI success more than technical capability. Future articles will dive deeper into each category, with specific diagnostic tools and tactical playbooks for navigating enterprise dynamics.
What I've found is that we are not facing mysterious forces. These are predictable human dynamics that smart founders can learn to navigate. The challenge is that most won't, because they're too busy falling in love with their algorithms to pay attention to organizational reality.
Because organizational reality is complex, but it's not random.
À suivre…(to be continued).
