A few days ago, someone showed me a webpage generated quickly by AI. Not only was it fast, but it also looked incredibly good. Someone joked that it was a "comedy version for the boss." But that instantly reminded me of the dire state of enterprise IT in reality, like at the company where a certain "Blind Date Guy" works.

Many people believe that as long as a product is well-made, it will sell. But if you try to sell a good product to large domestic enterprises or state-owned institutions, you have to deal with something called "bidding."

For a programmer with a perfectionist's obsession with product quality, bidding is simply the dregs of human civilization—a large-scale scripted murder mystery scene—and the ultimate desecration of a good product.

I. The Absurd Script Murder Mystery: A Carnival Named "Compliance"

Suppose Party A has a budget of one million. A bids 900,000, B bids 800,000, and C bids 500,000. Finally, let's congratulate C on winning the bid! Why? Because C secretly bribed the boss with 400,000.

This sounds like a joke, but real-world operations are only more refined and surreal.

1. Shooting the Horse to Catch the Horse and "Spec-Fitting" Before public bidding, Party A usually already has a designated preferred supplier (either due to strong connections or extensive preliminary groundwork). To complete the compliance process, this designated company helps Party A "write the tender documents," embedding "traps" in the technical specifications that only they can meet. For example, requiring the software to support a very obscure specific protocol; or providing an absurdly specific standard: "The device width must be exactly 412.34mm." Besides Product C, who else can meet this? This is a classic case of shooting the horse to catch the horse.

2. Bid-Runner Actors and Qualification Barriers Laws require at least three bidders for a tender; otherwise, the bid fails. To ensure a sure win, hiring two "actor companies" to participate as decoys is commonplace. To make the actors look realistic yet absolutely unable to win, the designated party helps them prepare their bid documents, intentionally inflating their quotes or leaving minor errors in the documents. This time you help me as a decoy, next time I help you, leading many companies to maintain a stack of miscellaneous qualification documents year-round, dedicated to playing this game.

Many technical directors naively believe that "writing good code and having a strong architecture" is enough to win. But in the bidding scoring sheet, technical aspects account for at most 30 points. What determines the remaining 70 points?

  • Registered Capital: The larger, the better.
  • Certificate Wall: ISO9001, CMMI, High-Tech Enterprise status, and even vague titles like "Integrity Model Unit."
  • Quantity Padding: No matter how poor the code is, the number of software copyrights must be sufficient, patents must be numerous, and even whether your employees hold "Software Professional Examination" certificates counts toward the score.

Consequently, to meet these bizarre parameters, companies are forced to hire dedicated staff to "fit the specs" and rush to purchase certificates.

3. The Scorch Earth War Where Bad Money Drives Out Good Even more ruthless is malicious low-bidding. Competitors first bid 0 to win, or even give away hardware for free. They first squeeze out honest technology companies, then recoup the money later through "maintenance fees," "Phase 2 projects," or "requirement changes." Furthermore, if the delivered system is intentionally held back (for example, if the computer is reinstalled, they cannot restore it themselves), they can later hold Party A's IT capabilities hostage.

In the face of such "science and harsh tactics," companies that truly understand technology simply cannot survive.

II. The Hodgepodge of National Flags and the Hellish Folding of EPC (General Contracting)

Do you really think that strictly following rigid scoring rules and selecting the product with the highest individual score is beneficial for the client? You are dead wrong. In reality, it is not uncommon to see the absurd operation of spending 10 million to buy two routers worth 10 dollars each.

Even if the entire process aligns with the original intent of the rules, the final procurement plan might be a nightmare combination like this: Microsoft AD + Apple Computers + Slack + Yahoo Mail + Amazon Cloud + Google Workspace.

What is the result? The computers cannot join AD, emails cannot integrate with documents, and Slack cannot be deployed on Amazon. AD refuses to interact with Google, while Slack requires a separate setup. Employees have to enter their passwords eight times a day just to log in. Single Sign-On (SSO) simply cannot be configured properly. Ultimately, cloud data has to be manually migrated using Excel. For operations and maintenance teams, the cost of managing such a heterogeneous environment increases exponentially.

But reality is ten thousand times worse—subcontracting (EPC) enters the picture.

To avoid the incompatibility of a "kitchen sink" mix of brands, the client usually issues a "general contracting bid." The client's calculation is clear: "I give the money to the general contractor, and the general contractor is responsible for assembling these components into a working package." But in reality, the general contractor takes a 1 million contract, turns around, and subcontracts 800,000 of it out. The next level then resells 600,000 of that. To maximize profits, the suppliers at the bottom will absolutely not buy the best but most expensive combination like "Microsoft + OpenAI." They will find a newly established small company to write a poor-quality chat software, or find a hardware company that casually includes an email system with no user interface.

In the end, the client ends up with a system that appears unified in branding on the surface but is actually full of junk. The result is: incompatibility, low quality, and low price. Users curse every day, while the procurer remains extremely safe.

III. Procedural Justice vs. Outcome Justice: The Fatal Pathology of Large Corporations

Why don't high-level think tanks know this? Why not directly have technically savvy people conduct the research and purchase a truly useful, highly compatible integrated solution (such as a full Microsoft, Google, or Feishu suite)?

Because in large organizations, the interests of the people who buy and the people who use are completely misaligned.

If leadership decides to buy the full Microsoft suite, and something goes wrong, or if they are reported for taking kickbacks, leadership will be unable to defend themselves. However, if they go through public bidding, even if they end up with a pile of e-waste or a terrible chat application, as long as the process is legal and every item on the scoring sheets is signed and stamped, leadership is exempt from liability. "It's not working well? That's a technical issue, not my integrity issue. The system isn't compatible? That's a vendor capability issue, but my procurement process is flawless." As long as they last until retirement, they land safely. For large enterprises and the government, procedural errors are capital offenses (potentially leading to jail), while mediocre results are merely a competency issue (at most, getting scolded).

This is why Microsoft can monopolize the enterprise market: initially not too expensive, packed with features, most certifications, established major brand, mediocre mainstream choice, preferred by the US military. Finance and audit departments understand these metrics. If a CTO recommends an open-source solution or a small company's product (like AnduinOS) that has the most advanced technical architecture and extremely elegant code, auditors will only see it as subjective mysticism, or even suspect kickbacks. In business decisions, mediocre but mainstream technology is always safer than advanced but niche technology. If something goes wrong with a major vendor, it's the major vendor's fault; if a bug occurs in a niche, cutting-edge technology and no one fixes it, everyone will blame you for being a maverick.

We programmers believe in result-oriented justice: as long as the tool is useful, the system is stable, and the code is awesome, I would willingly work overtime to grind out code. But the gravity of reality is too heavy; when you doubt the process too many times, countless colleagues who pursue result-oriented justice end up lying flat, ultimately becoming mere appendages of procedural justice.

4. The Ultimate Deadlock in Modern Corporate Management: Anduin's Impossible Triangle (CQE Theorem)

Based on all the absurd realities described above, I have summarized an "impossible triangle" in modern corporate management, which I call the CQE Theorem: When a large organization procures and operates, Compliance (without corruption), Quality (high quality and usability), and Efficiency (high efficiency) are absolutely mutually exclusive.

  1. Sacrificing Compliance (QE): Allowing the boss to make impulsive decisions, buying whatever catches their eye. This yields the best products with extremely high efficiency. However, it breeds backdoor dealings, opaque processes, and corruption. For example, in my own company, I can slightly sacrifice compliance to achieve high quality and high efficiency.
  2. Sacrificing Efficiency (CQ): Strictly following procedures, demanding both compliance and quality. The result is becoming like IBM or Volkswagen, where any single decision takes six months, and R&D is extremely slow.
  3. Sacrificing Quality (CE): This is the ultimate destination for the vast majority of companies. Compliance + Efficiency means writing the most perfunctory bid proposals possible and quickly buying a pile of legally compliant electronic junk.

Why is Quality (Q) always the first to be sacrificed? Because Compliance is a hard red line—crossing it means jail. Efficiency is a hard metric—being slow means getting scolded and having your year-end bonus docked. Quality, on the other hand, is a soft, mystical concept—if you say the code is bad, the boss doesn’t understand; if you say the architecture is poor, the auditors don’t care. As long as the software opens and the buttons can be clicked, "poor quality" is very difficult to define administratively.

Sacrificing invisible quality to preserve visible compliance and efficiency is the Nash Equilibrium in the game theory of large organizations.

This is not just a problem with the domestic system; it is the same all over the world.

  • Boeing used to pursue QH (in the 747 era, balancing quality and efficiency); in the McDonnell Douglas era, it shifted to CQ; later, to compete with Airbus, it chased H (efficiency) overnight, dropped Q, and became a purely CE company, resulting in the plane losing its door.
  • Apple used to be the embodiment of QE; now, to stabilize its stock price, it is also bowing to CE, first releasing a pile of immature AI electronic junk to secure its position.

V. Fleeing to Hong Kong Overnight: The Last Stand Against Mental Torture

That is exactly why I fled to Hong Kong overnight and shifted the company's focus. The domestic procurement and operational rules imposed on businesses are a pure mental torment for a developer who truly understands technology and has an obsession with product quality. Your kernel optimizations, your ecosystem synergy—these are worth only 2 points in the bidding parameters. You are even forced to twist your excellent product into a monstrous shape just to comply with the bid documents.

The Hong Kong market (and the global market) is not driven by procedural justice and relationship-oriented practices, but by result-oriented justice and product-driven values. There, no one cares about your registered capital. No one forces you to pad your bid documents with random, irrelevant parameters. Clients focus on one thing only: Is your SaaS tool easy to use? You put your product out there, and global users decide whether to use it or not. Integrate Stripe/PayPal, and the moment a user clicks subscribe, the money is in your account. There are no lengthy "acceptance reports," no "delayed project payments," and certainly no "year-end wage disputes."

In a world filled with CE (Compliance E-waste), the only way out for a technologist is to step out of the quagmire and face real users directly.