DDD-lite for founders who still code without a big rewrite

Why founder code gets messy fast

Founder code usually gets messy for a boring reason: speed wins. When the same person designs the feature, writes it, deploys it, and answers support, the easiest place to add a rule is wherever the code is already open.

A small change might start in a route handler. You add a check there, call a helper, patch a background job, then tweak a query so the data matches the new behavior. The feature works, but the rule now lives in three places that do not know about each other.

It gets worse when product rules hide inside UI checks. A button is disabled in the app, so the rule feels covered. Then a scheduled job, admin script, or API call skips that screen and does something the UI would never allow. Now the product behaves one way for users and another way in the backend.

Late fixes create the mess founders hate most: a bug that looks simple but changes behavior in two places. You patch the API because support found an edge case. A week later, the same bug comes back because the worker still uses the old helper. Nothing looks obviously broken on its own. The rule just has no single owner.

Debugging slows down fast at that point. You cannot open one file and answer a simple question like "Who can do this, and when?" You have to trace the rule through handlers, helpers, model methods, jobs, and raw SQL. Each piece makes sense by itself. Together, they turn a five minute fix into an afternoon.

That is where DDD-lite helps. The problem is rarely code volume by itself. The real problem is that business logic spreads into parts of the app that should only move data, render screens, or run tasks. Shipping still feels fast for a while. Changing your mind does not.

What DDD-lite means in practice

DDD-lite is a guardrail, not a grand system. You keep the parts of domain modeling that make business rules easy to read, test, and change. Everything else stays simple.

In practice, that means naming a few business concepts clearly and giving their rules one home. In a SaaS app, those concepts might be Trial, Subscription, SeatLimit, Invoice, or AccessPolicy. If a concept affects money, risk, or how work moves through the product, it deserves real code instead of being scattered across routes, UI handlers, and queries.

You do not need heavy diagrams, six layers, or a folder tree that looks impressive and slows you down. Most founder run products do not need repositories for everything, domain events for every change, or interfaces written for a future team that does not exist yet. If one plain method explains the rule best, use one plain method.

A simple test works well here: can you point to one place and say, "this file decides the rule"? If not, the rule will drift. That is when pricing breaks, permissions get weird, or support has to explain why two users saw different outcomes.

Framework code should stay in the delivery lane. A controller, API route, job, or React action should accept input, call the rule, and return the result. It should not decide who gets charged, when access ends, or whether an exception applies.

That split pays off quickly. Business rules stay readable, bugs are easier to trace, feature changes touch fewer files, and tests can focus on behavior instead of plumbing. That is why lightweight domain-driven design works well for founders who still ship their own code. You are not modeling the whole company. You are protecting the few rules that hurt when they get confusing.

If a rule changes revenue, access, approvals, or compliance, pull it out of the framework and name it well. Leave the rest alone.

Start with the words your product uses

If a customer says "trial", "workspace", or "seat", your code should say the same. Founder code gets messy when product language and code language drift apart. After a few quick fixes, "trial" turns into SubscriptionStatus, AccessManager, or plan_expires_at, and the rule becomes harder to read than the product itself.

Write down the nouns and verbs that already show up in sales calls, support tickets, onboarding notes, and pricing copy. You do not need a workshop for this. A plain list is enough if it captures the words people already use.

Then lock each term to one meaning. Trouble starts when "account" means a company in one file, a login in another, and a billing record somewhere else. Pick one meaning and rename the rest. Longer names often read better because they remove guessing.

A few renames usually help right away. TrialManager often becomes TrialPolicy or TrialExtension. UserService may really be CustomerAccount or TeamMemberAccess. Utils should almost always get a name that says what it actually does.

The same rule applies to business logic. Write rules in product words, not storage words. "A customer can extend a trial once" is clear. "Update subscription row if expires_at is before X" is a database step, not the business rule.

If your app stores trial dates in a subscriptions table, top level code should still read like trial.extendBy(7) or trial.canBeExtended(). Save methods and column names can sit underneath. When you debug a failed extension, you want to see the rule first and the SQL detail second.

That is most of DDD-lite. Choose the words your product already uses, keep their meaning stable, and push table names out of the main path. When a file reads like a product decision instead of a schema diagram, bug fixes get much faster.

Draw clear lines around each rule

When one handler parses input, checks business rules, updates the database, sends an email, and calls a payment API, bugs get muddy. You end up reading the whole function just to answer one question: did the user qualify, or did a side effect fail after the rule already passed?

A cleaner split starts with input. Let the controller, route, or worker turn messy outside data into plain fields your code can trust. Then pass those fields into a use case that answers one business question.

A use case should sound like a decision, not a transport task. "Can this customer pause billing?" is clear. "Handle pause subscription request" usually grows into a junk drawer.

Keep the state change next to the rule that allows it. If your product says a team can invite new members only while its plan is active, keep the check and the member count update in the same place. Do not check the rule in one file and update the account in another. That split looks tidy for a day or two, then it bites you.

You should be able to open one small area of code and see four things without hunting around: the facts the rule reads, the decision it makes, the data it changes, and the result it returns.

Everything else belongs outside that core. Email delivery, queue jobs, analytics calls, and third party APIs matter, but they are side effects. Run them after the business decision, not inside it.

That boundary helps more than people expect. If the rule says "approved" and the email provider times out, you still know the business decision was correct. You can retry the email without rerunning the rule and risking a duplicate update.

Refunds are a good example. One use case should decide whether the refund is allowed and mark the order accordingly. An outer layer can send the receipt email and notify accounting. When support asks why a refund failed, you inspect the rule code first, not the mailer, queue worker, and API client all at once.

A simple structure you can set up today

You do not need a rewrite to get readable business logic. Start small. A clean setup often begins with three folders: domain, use-cases, and adapters.

The split is simple. domain holds the rules your product must follow. use-cases holds the steps for one action, like extending a trial or refunding a payment. adapters holds outside details such as the database, email, billing, or a queue.

That gives each part one job. When a bug shows up, you can check the rule, then the flow, then the outside system. You stop digging through one giant file that mixes SQL, conditionals, and API calls.

Pick one rule that already causes pain. Do not move five at once. Choose something small but real, like "a trial can only be extended once" or "an invoice marked paid cannot return to draft."

Put that rule into a small domain object or a plain function. Keep it simple. It should not know about HTTP, ORM models, or background jobs. It only needs the data required for the rule and a method that returns a clear result.

Then put the database call behind a thin adapter. The use case can load a trial record, apply the rule, and save the result. The domain code stays easy to read because it does not care whether the data came from Postgres, Redis, or a test double.

A basic flow is enough: load data, call the rule, save the change. Before you touch the next feature, add one test for that rule. Just one is enough to start. If the rule says a second trial extension must fail, write that test first. It gives you a fixed point while you refactor.

This approach works best when you use it only where change happens often. Leave quiet code alone. Each time you touch a messy area, move one rule, add one test, and keep going. After a few weeks, the busiest parts of the app usually feel much calmer to debug.

A realistic example: extending a trial

A sales call ends with a simple promise: this account gets seven more days on the trial. It sounds tiny. In founder run products, it often turns into billing checks, plan exceptions, support notes, and one annoyed customer three weeks later.

A DDD-lite approach keeps that rule in one place. The controller should not decide anything. It should load the account, pass it to a domain object, ask for a decision, and react to the result.

Picture an Account or TrialPolicy object with a method like extendTrialByDays(7). That method can check the facts that matter to the business: whether the plan allows manual extensions, whether someone already granted one, and whether overdue invoices block it.

Then the object returns a clear answer. Yes, extend the trial. No, reject it. It should also return the reason in plain language, such as "extension denied: overdue invoice" or "extension denied: already extended once." That part matters. Six weeks later, you will not remember why the rule fired unless the code says it out loud.

The controller stays boring. It loads the account, asks for the decision, saves the result, and only then sends the email. If the answer is no, it sends the right message. If the answer is yes, it updates the trial end date and tells the customer the new deadline.

This split saves time when support gets a complaint. They do not need to inspect the controller, the billing code, and the email job. They check one place: the decision and its reason. If the reason looks wrong, you fix the rule once. If the reason is right, support can answer the customer without guessing.

That is the real win. The code matches the business rule closely enough that you can read it during a late night bug hunt and trust what it says. You do not need a big domain model. You need one small object that owns one real decision.

Mistakes that make DDD-lite heavy

DDD-lite goes wrong when structure shows up before the rule does. If you add repositories, services, use cases, factories, and policies before you can point to one business rule that needs protection, you built ceremony, not clarity.

Another common mistake is turning every database table into an object with methods and custom behavior. Most tables are just stored facts. A coupon row, a user row, or a webhook log often works fine as simple data while the real rule lives elsewhere.

The old mess can also come back under a nicer folder name. Teams move logic out of controllers, then bury it in helpers or shared modules with vague names. Six months later, nobody knows whether canRefund, checkRefund, or refundPolicy is the rule that actually matters.

If a decision affects money, access, or user promises, put it in one obvious place and call it by the business term. That makes bugs easier to trace and cuts down on guesswork when you are fixing something in a hurry.

Duplication is another tax founders pay later. A rule gets added in the app, then copied into a cron job, then copied again into a webhook handler and the admin panel. It works until one copy changes and the others do not.

Take a grace period rule for overdue invoices. It should not live separately in billing sync code, support tools, and the customer dashboard. One function or small module should answer that question for all of them.

Do not chase purity. You do not need an elaborate object model for every feature. If a plain function like canExtendTrial(account, today) makes the rule readable, testable, and easy to debug, stop there.

A boring smell test works well. Can you find the rule in under 30 seconds? Can the same code run from the API, admin tool, and background job? If yes, the structure is light enough. If not, cut layers before you add more.

Quick checks before you merge a feature

Before you merge, stop looking at the UI for a minute and look at the rule itself. If the rule feels spread out, oddly named, or hard to test, the bug will show up later when you are tired and moving too fast.

Start with ownership. You should be able to point to one file, or one small module, that owns the decision. If the same rule leaks into a controller, a worker, and a SQL query, pull it back before you merge.

Then check the names. They should match the words your team already uses. If support says "trial extension" but the code says promoWindow or bonusDays, people will talk past each other.

Check the test shape next. You should be able to test the decision without starting a web server. Give the rule plain inputs, check the result, and move on. If the test needs HTTP, auth, and a database, the rule is sitting in the wrong place.

Also keep logging, request parsing, and SQL at the edges. Parse the request first, call the rule second, save the result last. That order keeps business logic readable.

Finally, imagine tomorrow's bug report. If someone says, "paused accounts should not get extra trial days," would you change one place or three? If the answer is three, do not merge yet.

A simple example makes this obvious. Say you add a feature that lets sales extend a trial by seven days. The rule should live in one place that answers a plain question: can this account get an extension, and for how long? The controller can read the request. The database layer can save the new date. Neither should decide who qualifies.

This takes an extra 15 to 20 minutes on a feature branch. It often saves hours later. When you still design, ship, and debug your own product, readable business logic matters more than clever structure.

Where to go next

Do not refactor the whole app. Pick one workflow that keeps wasting your time and clean only that path.

Good starting points usually have a clear business rule and a real cost when they break. Trial extensions, plan changes, invite approvals, refund requests, and seat limits all fit. If support keeps asking the same question, or you keep rereading the same controller to understand one rule, start there.

A small pass usually works better than a grand redesign. Write down the product terms people keep mixing up. Pull the business rule into one obvious place. Add a couple of tests around money, access, or approval rules. Then ship that path and watch the next few bug reports. If people still get confused, adjust the names or the boundary.

If you want a second opinion before touching a production flow, oleg.is offers Fractional CTO and startup architecture help aimed at exactly this kind of cleanup. The useful part is usually not adding more patterns. It is removing confusion around the rules that drive revenue, access, and support work.

Start with one rule that hurts, not the whole codebase. If the code reads closer to the product decision after one afternoon of work, you picked the right place.