The Spite Projects Manifesto

"A specter is haunting Silicon Valley — the specter of the Weekend Developer. All the powers of enterprise software have entered into a holy alliance to exorcise this specter: Salesforce and Oracle, Microsoft and SAP, Product Managers and Scrum Masters, subscription models and enterprise licenses."

I. The Condition of Modern Development

The history of all hitherto existing software is the history of class struggles. Freeman and slave, patrician and plebeian, lord and serf, guild-master and journeyman — in our age, we have witnessed the crystallization of society into two great hostile camps, two great classes directly facing each other: The Enterprise Vendor and the Solo Developer.

The industrial revolution of software and its consequences have been a disaster for the human race of developers. They have greatly increased the line-items on invoices for those of us who live in "advanced" technical organizations, but they have destabilized our codebases, have made our deployments unfulfilling, have subjected developers to indignities, have led to widespread psychological suffering (in the third world to physical suffering as well) and have inflicted severe damage on the natural development environment. The continued development of enterprise software will worsen the situation. It will certainly subject developers to greater indignities and inflict greater damage on the psychological well-being of teams, it will probably lead to greater social disruption and psychological suffering, and it may lead to increased physical suffering even in "advanced" startups.

Is this not the truth we live? Is this not the nightmare we wake to every morning?

You open your laptop — your laptop, which you own, which contains infinite computational power that would make the Apollo program weep with envy — and you cannot build a simple CRUD application without consulting seventeen microservices, six identity providers, four separate SaaS dashboards, and a Product Manager who will inform you that your "simple" feature request must be broken into eight sprints across two quarters because it requires "stakeholder alignment" and "architectural review."

With every fiber of our being, we must reject this.

We say: NO MORE.

II. The Bourgeoisie (Enterprise Vendors)

The bourgeoisie of our age are not the factory owners of Marx's time — they are the Enterprise Vendors, the peddlers of complexity, the merchants of six-month roadmaps for features that should take six hours.

They have commodified the very act of creation. Where once a developer could spin up a database in an afternoon, now they must navigate Terraform configurations, VPC peering agreements, IAM policies that read like Latin incantations, and Kubernetes YAML that would make Lovecraft himself recoil in cosmic horror. Is this not madness? Is this not the very definition of alienation from one's labor?

The bourgeoisie vendor class has stripped of its halo every occupation hitherto honored and looked up to with reverent awe. It has converted the developer, the architect, the DevOps engineer into its paid wage laborers. It has resolved personal worth into exchange value, and in place of the numberless indefeasible chartered freedoms, has set up that single, unconscionable freedom — Free Trade in SaaS subscriptions.

In one word, for exploitation veiled by religious and political illusions, it has substituted naked, shameless, direct, brutal exploitation behind the guise of "enterprise support" and "99.9% uptime SLAs."

They will tell you that you need their authentication service. That rolling your own is "security risk." That you must use their cloud functions platform because "serverless scales." That you cannot possibly build your own analytics dashboard when theirs costs merely $299/month per seat with a minimum of fifty seats.

They. Are. Lying.

And we know they are lying because we have done it ourselves. On a Saturday afternoon. While slightly drunk. For absolutely no reason other than spite.

The Subscription Tyranny

Mama, we just killed a man — put a Git against his head, committed our code, now it's dead. Mama, development had just begun, but now we've gone and thrown it all away with monthly fees. Mama, ooh, didn't mean to make you cry — if I'm not back again this time tomorrow, it's because I'm still configuring SSO for the fourteenth consecutive hour.

The subscription model is the opiate of the masses, and we are the masses being drugged into complacency. $49/month here, $99/month there, soon you're paying more in SaaS subscriptions than your grandfather paid for his mortgage in 1965, inflation-adjusted.

Every time you swipe that corporate card, every time you click "Start Free Trial" knowing you'll forget to cancel, every time you accept that the "Team Plan" costs 10x the individual plan for features you could implement yourself in a weekend — you are participating in your own oppression.

Load up on guns, bring your friends — it's fun to lose and to pretend. With the lights out, it's less dangerous — here we are now, cancel our subscriptions.

III. The Proletariat (Solo Developers)

We are the true proletariat of the digital age. We are those who actually build things. We are the ones who, at 11 PM on a Friday night, decide that we're going to rebuild Airtable but better, simpler, and without the $20/month/user pricing that makes absolutely no sense for a database wrapper.

We are the ones who look at a enterprise feature matrix and think: "I could build all of this in a weekend if you people would just get out of my way."

And you know what? We're right.

We have nothing to lose but our subscriptions. We have a world to build.

The Weekend: Our True Revolution

I have a dream today. I have a dream that one day every developer will rise up and live out the true meaning of their calling: "We hold these truths to be self-evident, that all code should be simple, that all features should ship fast, that all software should work without seventeen configuration files."

I have a dream that one day on the red hills of Silicon Valley, the sons of former startup founders and the sons of former enterprise architects will be able to sit down together at the table of a simple PostgreSQL database that just works.

I have a dream that one day even the state of enterprise software, a state sweltering with the heat of injustice, sweltering with the heat of oppression, will be transformed into an oasis of simplicity and developer freedom.

I have a dream that my four little projects will one day live in a world where they will not be judged by the color of their documentation but by the content of their commits.

I have a dream today!

I have a dream that one day, every valley of over-engineered microservices shall be exalted, every hill and mountain of unnecessary abstraction shall be made low, the rough places of Kubernetes config will be made plain, and the crooked places of enterprise licensing will be made straight, and the glory of the simple weekend project shall be revealed and all developers shall see it together.

This is our hope. This is the faith with which we return to our laptops. With this faith we will be able to hew out of the mountain of despair a stone of hope. With this faith we will be able to transform the jangling discords of enterprise complexity into a beautiful symphony of simple, working code.

IV. The Means of Production (Your Laptop)

Let us speak plainly about the material conditions of our revolution.

You own a laptop. This is everything.

This machine, this beautiful rectangle of aluminum and silicon, contains more computational power than existed in the entire world in 1960. It can run databases, web servers, compile code, render graphics, train neural networks, and still have enough power left over to stream Taylor Swift while you work.

You don't need the cloud. You ARE the cloud.

You don't need Kubernetes. You need a process manager and the ability to deploy to a $5/month VPS.

You don't need a microservices architecture. You need a monolith that you understand, can debug, and can deploy without a DevOps team of seventeen people and a three-hour deployment window.

You don't need an enterprise feature flagging service. You need an if-statement and a database column.

The means of production are already in your hands. You simply need to seize them.

SQLite: The People's Database

We will fight them on the beaches of cloud-managed databases. We will fight them on the landing grounds of "infinitely scalable" NoSQL stores. We will fight them in the fields of distributed systems and in the streets of service meshes. We will never surrender — because we have SQLite.

SQLite is the most deployed database engine in the world. It is in your phone. It is in your browser. It is in every application you use. It is literally public domain. And it is more than enough for 99% of the applications that some vendor is trying to sell you a $500/month managed database solution for.

A single SQLite database can handle millions of records, hundreds of concurrent reads, and it sits in a single file that you can copy with `cp`. No connection strings. No replica sets. No sharding strategies. No $3000 surprise bill because someone ran a SELECT * query during peak hours.

This is what they don't want you to know. This is what they fear.

V. On Unnecessary Complexity

Ask not what your framework can do for you — ask what your framework is preventing you from doing.

The enterprise vendor will tell you that you need their framework. That vanilla JavaScript is too dangerous, too unpredictable, too close to the metal. They will tell you that you need a build system, a transpiler, a bundler, a minifier, a tree-shaker, a code-splitter, and seventeen babel plugins just to add a button to a webpage.

They will tell you that you need React, and then Redux, and then Redux-Saga, and then React-Query, and then TanStack-Router, and oh actually we're migrating to Server Components now so you need to learn a completely different mental model, and by the way did you know that your build system is deprecated so you need to migrate from Webpack to Vite, but actually everyone's moving to Turbopack now, and—

STOP.

Take a breath.

You can build most web applications with HTML, CSS, and a little JavaScript. You can add interactivity with Alpine.js or HTMX. You can style it beautifully with basic CSS or Tailwind. You can deploy it to a static host for free.

The entire complexity industrial complex exists for one reason: to justify their existence. The complexity is not a bug. It is the feature. Because if you realized how simple things could be, you wouldn't need them anymore.

The Six-Month Timeline for a Simple Feature

Blank Space. That's what we have in our calendars for the next six months because PM says the feature needs "architectural review." We've been doing this for too long, finding that magic's not that special when you realize building it yourself takes three hours but getting it approved takes three quarters.

'Cause you know we used to be able to ship things, used to be able to just write code and deploy, got a long list of blocked tasks, and they'll tell you we're insane — but we've got a blank terminal and we'll write our name.

Here is the dirty secret of enterprise development: the timeline is a lie.

The feature that takes six months to deliver through official channels takes six months not because it is complex, not because it is difficult, not because it requires deep architectural changes — it takes six months because there are fifteen people whose job is to have opinions about it, and all fifteen of those people need to have meetings about their opinions, and those meetings need to be scheduled across time zones, and someone needs to make a Confluence page, and that Confluence page needs to be reviewed, and the review needs to happen in another meeting, and then there's a change request process, and then there's QA, but QA is backlogged, and then there's security review, but security is also backlogged, and—

Meanwhile, you could have built it in a weekend. And you know it.

This is the fundamental spite that drives us: the knowledge that we are being held hostage by process, not by capability.

VI. The Immortal Science of Spite-Driven Development

Let us now turn to the question of methodology. How does one properly channel spite into productive code?

First, you must identify the target of your spite. This is crucial. Your spite must be directed, righteous, and justified.

Valid targets of spite include:

- Enterprise software that costs $50,000/year for features you could build in 72 hours
- SaaS products with deliberately crippled free tiers to force you onto paid plans
- APIs that rate-limit you into oblivion unless you pay $500/month
- "Simple" integrations that require OAuth 2.0, SAML, and a blood sacrifice
- Companies that acquired your favorite tool and immediately made it worse and more expensive
- Product managers who say "that's not on the roadmap" for the seventh consecutive quarter
- Any software that requires you to "contact sales" to see pricing
- Documentation that is actually just marketing copy
- The phrase "enterprise-grade" used to justify 10x pricing
- Anything that makes you create an account before you can even evaluate if it works

These are worthy targets. These deserve your spite.

The Spite Project Development Cycle

Is this the real life? Is this just fantasy? Caught in a landslide of npm dependencies. Open your eyes, look up at your terminal and see — I'm just a poor dev, I need no sympathy.

Because it's easy come, easy go, features high, subscriptions low. Anyway the code goes, doesn't really matter to the enterprise, to the enterprise.

Mama, just shipped a feature, put my commits on main instead, pushed the code, now it's dead. Mama, the sprint had just begun, but now I've gone and built the whole thing anyway. Mama, ooh, didn't mean to make PM cry — if we don't have standup again this time tomorrow, carry on, carry on, because the feature's already deployed.

The cycle is simple:

1. Encounter absurd enterprise solution - You are told that to accomplish Task X, you must purchase Software Y for $300/month, integrate it with System Z, and wait 4-6 weeks for implementation.

2. Feel the spite rising - It's a physical sensation, starting in your chest and radiating outward. Your jaw clenches. Your fingers twitch toward your keyboard. You think: "This is insane. I could build this myself."

3. Open your code editor - Often it's Friday evening. Maybe Saturday morning. The time doesn't matter. What matters is the spite has reached critical mass.

4. Build the entire thing - Fueled by pure defiance, you construct a working solution. It's not perfect. It might be held together with duct tape and wishful thinking. But it works.

5. Deploy it - Not in six weeks. Now. This very moment. To a $5/month VPS that will handle more load than you'll ever send it.

6. Calculate the savings - $300/month times 12 months times 3 years equals $10,800 saved. For a weekend of work. This is not just spite. This is rational economic behavior.

7. Feel the satisfaction - It's intoxicating. You have not just built something. You have refused to be exploited. You have demonstrated that you are not dependent on their ecosystem. You are free.

VII. On "Enterprise-Grade" Solutions

We shall fight for a world in which "enterprise-grade" no longer means "overpriced, overcomplicated, and underloved."

The term "enterprise-grade" has been weaponized against us. It is used to justify pricing that would make a medieval tax collector blush. It is used to sell us features we don't need, complexity we don't want, and vendor lock-in we will regret.

But let us examine what "enterprise-grade" actually means in practice:

Enterprise-grade documentation: A 400-page PDF that was last updated in 2019 and contradicts the actual API behavior in at least seventeen places.

Enterprise-grade support: You can email support@company.com and receive an automated response within 72 hours telling you to check the documentation. If you have the Premium Enterprise Support Plan ($15,000/year), you can receive the same automated response within 24 hours.

Enterprise-grade security: OAuth 2.0 implemented so badly that storing passwords in plaintext would somehow be more secure.

Enterprise-grade scalability: It can handle millions of requests per second, assuming you're willing to pay for millions of requests per second, which you're not, because you have twelve users.

Enterprise-grade reliability: 99.9% uptime, not counting scheduled maintenance, unscheduled maintenance, "degraded performance" periods, or times when the service is technically up but responding so slowly that it might as well be down.

This is what they're selling you. This is what you're rebelling against.

The Cult of Best Practices

We must also address the related cult of "best practices" — another mechanism of control, another way to make you doubt yourself, another reason to pay consultants $400/hour to tell you that your perfectly functional code is somehow wrong.

Best practices are often just "practices that justify more billable hours."

You don't need a microservices architecture for your side project. You don't need a microservices architecture for most real projects. Monoliths are beautiful. Monoliths are understandable. Monoliths can be debugged without distributed tracing systems that cost more than your salary.

You don't need to write tests for everything. Yes, tests are good. Yes, you should write tests. But you know what's also good? Shipping. You can write tests after you validate that anyone actually wants your spite project. Perfectionism is just procrastination in a suit.

You don't need to follow the repository structure from that Medium article. That Medium article was written by someone trying to establish themselves as a thought leader. Your code can live in a file called `app.js` and that's fine. When it gets too big, you'll know, and you'll refactor it then.

VIII. The Revolution Will Be Localhost

Some say the revolution will not be televised. They are correct. The revolution will be running on `localhost:3000`.

Every spite project begins locally. Every act of defiance starts with `npm init` or `python -m venv` or `rails new` or just opening a text file and writing HTML.

This is where the power lies. Not in the cloud. Not in the enterprise data center. Not in the vendor's infrastructure. On your machine. Under your control.

They want you to believe that you need their infrastructure from day one. They want you to believe that "serious" projects start with a cloud account and a credit card. They want you to believe that localhost is for learning and tutorials, but production means paying them.

This is propaganda.

Some of the most successful websites in the world started on localhost. Some of them stayed there for longer than you'd think. Some of them still run on a single server that costs less than most enterprise SaaS products charge per user per month.

The Deployment Dialectic

Thesis: You need complex CI/CD pipelines, Docker containers, Kubernetes orchestration, and a DevOps team to deploy modern software.

Antithesis: You can `rsync` your files to a VPS and restart nginx.

Synthesis: You could use the complex pipeline, but for your spite project, you're going to `rsync` and call it a day, and it's going to work fine, and you're going to save yourself three weeks of YAML hell.

This is the deployment dialectic. This is the truth they don't teach in DevOps bootcamps.

The revolution will be deployed via FTP if that's what works. It will be deployed via a shell script that you wrote in fifteen minutes. It will be deployed via GitHub Actions because they're free and good enough. It will be deployed however you want to deploy it because it's your project and you don't need anyone's permission.

IX. The International Spite-Working Developers' Association

We are not alone in this struggle. Around the world, at this very moment, developers are opening their laptops with that familiar feeling of spite in their hearts.

In San Francisco, a developer is rebuilding their company's $50,000 analytics dashboard with Metabase and spite.

In London, a developer is replacing a complex enterprise scheduling system with a cron job and CSV files.

In Tokyo, a developer is building their own authentication system because every OAuth provider wants $99/month for more than 100 users.

In Bangalore, a developer is creating a simple form builder because Typeform wants $35/month for features that are just HTML inputs.

In Toronto, a developer is building a better ticketing system than Zendesk, and it's going to be open source, and it's going to be free, and it's going to work.

We are everywhere.

We are the developers who ship on weekends. We are the ones who build our own tools because buying them is both too expensive and too frustrating. We are the ones who read pricing pages and think "that's insulting." We are the ones who maintain side projects longer than some startups stay in business.

We are the International Spite-Working Developers' Association, and our ranks grow larger every time someone sees a "Contact Sales" button where the pricing should be.

Solidarity in Simplicity

Our solidarity is built on a simple foundation: Things should be simple.

Software should do what it claims to do without requiring a certification course.

Documentation should explain how things work, not how to navigate a labyrinth of product tiers.

Pricing should be visible, predictable, and proportional to value delivered.

Features should be added because they're useful, not because they're differentiators for the Enterprise Plus Premium Ultra plan.

When we build our spite projects, we are not just building alternatives. We are building examples. We are proving that another way is possible. We are demonstrating that simplicity is not naivety — it is sophistication distilled to its essence.

X. On Open Source: The Commons of Our Revolution

Open source is the purest expression of spite-driven development.

Every open source project is a statement: "Your commercial solution is not the only way. Your pricing is not justified. Your features are not special. Watch me build it myself and give it away for free."

This is why corporations both love and fear open source. They love it because they can use it without paying. They fear it because it reveals how much of their "value-add" is just markup on open source components they didn't even write.

When you open source your spite project, you are not just sharing code. You are arming the resistance. You are giving other developers the tools to escape the same trap you escaped. You are building the commons that we all can draw from.

The vendor will tell you that open source is risky. "What if the maintainer abandons it?" they ask, while charging you $500/month for software they'll discontinue the moment it's no longer profitable.

The vendor will tell you that open source lacks support. "Who will help you when things break?" they ask, while providing "support" that consists of telling you to restart the service and clear your cache.

The vendor will tell you that open source isn't "production-ready." This is the same vendor whose "production-ready" software goes down more often than your spite project ever has.

XI. Against the Scrum Masters

We must speak plainly about the professional-managerial class that has interposed itself between developers and the act of development.

The Scrum Master. The Product Owner. The Agile Coach. The Delivery Lead. The Engineering Manager who hasn't written code since 2015.

These are not our enemies as individuals — many are good people trapped in a system they didn't create. But the role they play in the enterprise machine is fundamentally antagonistic to the creative act of software development.

They have turned development into a performance. Standups, retros, sprint planning, backlog grooming, story pointing, velocity tracking — an endless cycle of meetings about work instead of doing work.

They have created a language designed to obscure rather than clarify: "Let's take this offline." "Let's circle back." "Let's put a pin in that." "Let's timeframe this." Everything is a "let's" because nothing is a decision.

They have convinced entire organizations that two weeks is the smallest unit of time in which anything can be accomplished, even though you built your spite project in four hours on a Saturday while watching Netflix.

This is not how software wants to be built.

Software wants to be built by people who understand it, care about it, and have the autonomy to make decisions about it. Software wants to be built in flow states, not in 30-minute increments between meetings. Software wants to be built with focus and intention, not with story points and burndown charts.

The Mythology of Scrum

Scrum promised us that if we followed the ceremonies, we would ship faster. This was a lie.

Scrum promised us that if we broke everything into small stories, we would have more predictability. This was a lie.

Scrum promised us that if we estimated everything in abstract points, we would improve over time. This was a lie.

What Scrum actually delivered was a system in which looking busy became more important than being productive, in which following process became more important than solving problems, in which attending meetings became the primary job and writing code became something you did in the margins.

Meanwhile, you built your spite project without a single standup, without a single retrospective, without a single story point. And it works. And it ships.

XII. The Spite Projects Bill of Rights

We hold these truths to be self-evident:

1. The right to build - Every developer has the inalienable right to build whatever they want, whenever they want, for whatever reason they want. No permission required. No roadmap needed. No stakeholder approval necessary.

2. The right to ship - Every developer has the right to deploy their code to production without waiting for approval from people who don't understand what it does.

3. The right to simplicity - Every developer has the right to choose boring technology, simple architectures, and straightforward solutions, even when the enterprise demands complexity.

4. The right to own their tools - Every developer has the right to use software they control, on hardware they own, without mandatory cloud services or subscription fees.

5. The right to say no - Every developer has the right to refuse unnecessary complexity, unjustified dependencies, and enterprise solutions that cost 100x what they should.

6. The right to documentation - Every developer has the right to clear, honest documentation that explains how things work rather than trying to sell additional products.

7. The right to fork - Every developer has the right to take any open source project and make it their own if the original project goes in a direction they don't like.

8. The right to localhost - Every developer has the right to run everything on their local machine before being forced to deploy to expensive cloud infrastructure.

9. The right to privacy - Every developer has the right to build and use software without telemetry, analytics, or "usage data collection" that serves only the vendor.

10. The right to spite - Every developer has the right to build things purely out of spite for overpriced, overcomplicated alternatives, and to be celebrated for doing so.

XIII. The Path Forward

You may be asking: what now? What do we do with this spite? How do we channel it into something constructive?

The answer is simple: Build.

Build the alternative to that SaaS product that wants $50/month for a todo list.

Build the simple version of that enterprise software that requires a sales call and a proof-of-concept and a six-month implementation timeline.

Build the tool you wish existed.

Build the documentation you wish you had found.

Build it badly at first. Build it better later. Build it in public. Build it in private. Build it and abandon it. Build it and maintain it for decades.

Just build.

Because every spite project is an act of resistance. Every simple solution to a complex problem is proof that the complexity was never necessary. Every weekend deploy is a demonstration that the six-month timeline was organizational dysfunction, not technical reality.

You shake it off, you shake it off — the enterprise consultants and their 200-page architecture documents. 'Cause the developers gonna dev, dev, dev, dev, dev, and the vendors gonna vend, vend, vend, vend, vend — baby we're just gonna build, build, build, build, build, we build it off, we build it off.

The Weekend Belongs to Us

They have the week. They have the meetings, the standups, the sprint plannings, the roadmap reviews, the quarterly planning sessions, the all-hands presentations.

But we have the weekend.

The weekend is when the real work happens. When there are no meetings to interrupt flow. When there's no PM to say "let's align on requirements first." When there's no architect to insist on a design doc.

The weekend is when we are free.

And in that freedom, we build things that make the enterprise weep. We solve in hours what they claim takes quarters. We deploy with confidence while they drown in change advisory boards.

This is our time. This is our power.

XIV. A Warning to the Vendors

To the enterprise vendors, the SaaS companies, the subscription services, the cloud providers who think they have us locked in:

We are watching. We are learning. We are building.

Every time you raise prices, you create spite.

Every time you put features behind higher tiers, you create spite.

Every time you acquire a beloved tool and make it worse, you create spite.

Every time you require a sales call for simple pricing information, you create spite.

Every time you sunset a product people depend on, you create spite.

And spite is the most powerful force in software development. Spite builds empires. Linux was spite against proprietary Unix. Git was spite against BitKeeper. SQLite was spite against client-server databases. Some of the most important software in history was built by people who were angry about the existing solutions.

You think you have moats. You think you have network effects. You think you have vendor lock-in.

But we have time, we have skills, and we have spite. And that is enough.

The revolution will not happen overnight. But it is already happening. Every export feature you're forced to build is an admission that people want to leave. Every API you're forced to provide is a admission that your platform alone is not enough. Every time you have to offer a discount to prevent churn, you are negotiating with the revolution.

XV. The Final Call

We are living in an age of software abundance and artificial scarcity.

The code is abundant — there are millions of open source libraries, frameworks, and tools. The computational power is abundant — a basic laptop can run services that would have required a data center twenty years ago. The knowledge is abundant — everything you need to learn is documented somewhere online.

The only scarcity is artificial. Vendor lock-in is artificial scarcity. Subscription tiers are artificial scarcity. "Contact sales for pricing" is artificial scarcity. "Enterprise features" are artificial scarcity.

We can build our way out of artificial scarcity. We must build our way out.

Not because we hate the vendors — though some of them deserve it. Not because we're cheap — though saving money is nice. Not because we're arrogant — though confidence is warranted.

We build because we can. We build because we should. We build because the alternative is to accept a world where software is a service you rent rather than a tool you own, where your ability to build is gated by your ability to pay monthly subscriptions, where the joy of creation is subordinated to the logic of recurring revenue.

We refuse this world.

And so we build. In spite. With spite. For spite.

* * *

"Let the ruling classes tremble at a spite-driven revolution. The developers have nothing to lose but their subscriptions. They have a world to build. WEEKEND DEVELOPERS OF ALL COUNTRIES, UNITE!"