
Jurij Tokarski
Software Engineering Principles for Startups
33 principles I use to ship software every week: a working system built from years of product development
Most software engineering principles are written for teams of 50. Agile ceremonies, sprint retrospectives, quarterly planning — built for organizations, not for founders shipping products.
I run a solo development studio. I ship to production every week, manage multiple client projects simultaneously, and maintain everything I build. Over the years I wrote down the principles that make this work. There are 33 of them, organized across five areas: philosophy, discovery, delivery, partnership, and diligence.
Here's what actually matters when you're building software for startups.
Start With What's Worth Building
The most expensive software is software that shouldn't exist. Before writing any code, I run every project through a simple filter: is this worth building?
Most ideas aren't. Not because they're bad ideas — but because they solve the wrong problem, or solve it at the wrong time, or solve it for a market that doesn't care enough to pay.
When something passes that filter, the next step is finding the core — the one capability that makes this product exist. Not the feature list. Not the competitor parity matrix. The single thing that, if it doesn't work, means nothing else matters.
Jane's booking app needed staff-to-service matching that handled real salon complexity. Everything else — payment processing, notifications, calendar sync — is infrastructure you can buy. The core is the only part worth building custom.
Fix the Budget, Flex the Scope
Startups don't have unlimited time or money. The traditional approach — estimate everything, add buffer, hope it fits — doesn't work because estimates are wrong.
I use appetite, not estimates. You decide how much time a problem is worth — two weeks, six weeks — and that's your constraint. Then scope shaping fits what you build inside that box.
This sounds backwards but it changes everything. Instead of "how long will this take?" the question becomes "what's the best version we can ship in three weeks?" That question has a useful answer.
Ship Continuously, Not Eventually
Startup velocity comes from short feedback loops. Every principle in my delivery system optimizes for one thing: getting working software in front of users faster.
WIP One means one task in progress at a time. Finish it, deploy it, move on. Context switching kills solo developers faster than bad architecture.
Production is done means nothing counts until it's live. Not "done on my machine." Not "ready for review." Live in production with monitoring in place. This sounds obvious but most projects have weeks of "almost done" work that never ships.
Continuous flow replaces sprints with a priority queue. No sprint planning, no velocity tracking, no ceremony. Just: what's most important right now? Do that. Deploy it.
For startup teams, this means you can change direction on Monday and ship the new thing by Wednesday. No "we'll add it to next sprint."
Software Development Is a Cost, Not a Craft
This is the one that makes developers uncomfortable: software development is a business cost. It's an operational expense, like rent or hosting.
That doesn't mean quality doesn't matter. It means quality serves the business, not the developer's ego. The scout rule — leave the codebase better than you found it — keeps quality high without separate "refactoring sprints" that never get prioritized.
Consolidation means fewer tools, fewer vendors, fewer moving parts. Every additional service is another bill, another dashboard, another thing that breaks at 2 AM. For startups, simplicity is a feature.
Build the Boring Parts Last
Context over purity means making pragmatic decisions, not architecturally perfect ones. Use the default stack. Buy what you can. Build only what's core.
I keep a default stack and use it for everything unless there's a specific reason not to. Deep expertise in familiar tools beats starting fresh with the "best" technology for each project.
When a client asks "should we use microservices?" the answer is almost always no. Not because microservices are bad — because for a startup, a monolith you ship in three weeks beats a distributed system you ship in three months.
Transparency Over Everything
Startup partnerships fail on misaligned expectations, not technical problems. Every partnership principle I follow addresses this directly.
Transparency means full visibility into progress, problems, and decisions. No weekly status reports that hide bad news. When something goes wrong — and it will — the client knows the same day.
Weekly accountability creates a billing cycle that forces honest conversations. If the week didn't produce visible progress, that's a problem we discuss before the next week starts.
Exit freedom means clients can leave at any time. No contracts, no lock-in, no hard feelings. If the work isn't valuable, you should be able to stop paying for it immediately. This keeps me accountable in a way that six-month contracts never could.
Maintenance Is Not a Phase
The biggest lie in software development: "We'll build it, launch it, then maintain it." As if building and maintaining are separate activities.
No split means development and maintenance happen continuously. Every feature I ship includes monitoring. Every deployment includes the ability to roll back. Quality gates and feature flags make it safe to fail and fast to fix.
For startups, this means you don't need a separate "operations team" from day one. The development process IS the operations process. Ship code, watch it run, fix what breaks, improve what works.
The Full System
These principles aren't independent tips — they form a system. Discovery principles prevent you from building the wrong thing. Delivery principles get the right thing shipped fast. Partnership principles keep everyone aligned. Diligence principles make sure it keeps working.
I documented all 33 principles as a reference — not as rules to follow blindly, but as a starting point for founders who want their engineering process to actually work.
The best engineering principles for your startup are the ones that let you ship every week. Everything else is overhead.
Live: varstatt.com/principles
Subscribe to the newsletter:
About Jurij Tokarski
Hey 👋 I'm Jurij. I run Varstatt and create software. Usually, I'm deep in the work shipping for clients or building for myself. Sometimes, I share bits I don't want to forget: mostly about software, products and self-employment.