DEV Community: esde_site

I Built an Open-Source Seller Earnings Calculator for Software Marketplaces

esde_site — Fri, 17 Jul 2026 17:11:19 +0000

Selling a software product for €49 does not mean the seller earns €49.

Marketplace commissions, payment-processing fees, VAT, refunds, affiliate commissions, and fixed transaction costs can reduce the final payout significantly.

The calculation becomes even more confusing when VAT is already included in the displayed price.

I ran into this problem while building esdecode, a marketplace for source code, scripts, plugins, templates, applications, and other developer assets.

To make the fee structure easier to understand, I built a free Seller Earnings Calculator and published its core calculation engine as an open-source TypeScript project.

Why seller revenue is harder to calculate than it looks

A basic revenue calculation is simple:

Product price × Number of sales

If a product costs €49 and is sold 20 times:

€49 × 20 = €980

But €980 is not necessarily the seller's actual revenue.

Several deductions may still apply:

VAT or sales tax
marketplace commission
payment-processing percentage
fixed payment fee per transaction
refunds
chargebacks
affiliate commissions
advertising costs
other fixed selling expenses

The order in which these deductions are applied also matters.

For example, a marketplace might calculate its commission from the price excluding VAT, while the payment provider might calculate its fee from the full amount paid by the customer.

The VAT-inclusive pricing problem

One of the most common calculation mistakes is treating VAT included in a price as a simple percentage of that price.

Suppose a product costs:

€120 including 20% VAT

The VAT amount is not:

€120 × 20% = €24

That would be correct only if VAT were being added on top of a €120 base price.

When VAT is already included, the correct calculation is:

VAT =
Gross price - Gross price / (1 + VAT rate)

For a €120 VAT-inclusive price:

Base price: €100
VAT: €20
Customer total: €120

This distinction affects every fee calculated after VAT is separated from the seller's revenue.

Three VAT modes

The calculator supports three VAT modes.

VAT included in the product price

The entered price is the final amount paid by the customer.

Example:

Product price: €49
VAT: 20% included

The calculator extracts the VAT portion from the price before calculating revenue excluding VAT.

VAT added on top

The entered product price is the seller's base price.

Example:

Base product price: €49
VAT: 20%
Customer total: €58.80

In this mode, payment-processing fees may apply to the complete customer payment, including VAT.

VAT not applied

This mode can be used for estimates where VAT is not relevant or is handled separately.

It may apply when:

the seller is not VAT registered,
reverse charge is used,
the marketplace handles tax independently,
the user only wants a fee estimate without tax.

The calculator is only an estimation tool. Actual tax treatment depends on the seller, buyer, marketplace, and jurisdiction.

Marketplace commission

A marketplace normally retains a percentage of each sale.

For example:

Revenue excluding VAT: €816.67
Marketplace commission: 20%

The commission would be:

€816.67 × 20% = €163.33

The calculation engine uses revenue excluding VAT as the default marketplace commission base.

This is an assumption, not a universal rule. Each marketplace may define its commission differently.

Payment-processing fees

Payment providers commonly use two fee components:

Percentage fee + Fixed fee per transaction

For example:

2.9% + €0.30 per transaction

For 20 sales with a customer total of €980:

Percentage fee:
€980 × 2.9% = €28.42

Fixed fees:
20 × €0.30 = €6.00

Total payment-processing fees:
€34.42

Fixed fees can have a large effect on inexpensive products.

A €0.30 transaction fee represents:

3% of a €10 sale,
approximately 0.6% of a €49 sale,
only 0.15% of a €199 sale.

This is one reason low-priced digital products may have a much lower effective profit margin.

Refund estimates

Refunds are another cost sellers frequently underestimate.

A product with €10,000 in gross sales and a 5% refund rate may lose approximately:

€10,000 × 5% = €500

The actual impact can be higher if the payment provider does not return the original processing fee.

Chargebacks may introduce additional costs beyond the original sale amount.

The first version of the calculator treats refunds as a percentage of customer-facing sales. This assumption is documented in the calculation methodology.

Affiliate commissions

If a seller pays affiliates for referred sales, the affiliate percentage also needs to be included.

For example:

Revenue excluding VAT: €5,000
Affiliate commission: 15%

Estimated affiliate cost:

€5,000 × 15% = €750

Affiliate sales can still be profitable, but they need to be evaluated based on net revenue rather than gross sales.

Example calculation

Consider the following scenario:

Product price: €49
Number of sales: 20
VAT: 20% included in price
Marketplace fee: 20%
Payment-processing fee: 2.9%
Fixed payment fee: €0.30 per transaction
Refund rate: 0%
Affiliate commission: 0%
Other costs: €0

Customer revenue

€49 × 20 = €980

Revenue excluding VAT

€980 / 1.20 = €816.67

VAT

€980 - €816.67 = €163.33

Marketplace commission

€816.67 × 20% = €163.33

Payment percentage fee

€980 × 2.9% = €28.42

Fixed transaction fees

20 × €0.30 = €6.00

Estimated seller earnings

€816.67
- €163.33 marketplace commission
- €28.42 payment percentage fee
- €6.00 fixed payment fees
= €618.92

The seller keeps approximately:

€30.95 per sale

This example demonstrates why the product price alone is not enough to understand the real seller payout.

What the calculator includes

The live calculator supports:

product price
expected number of sales
multiple currencies
marketplace commission
payment-processing percentage
fixed transaction fees
VAT included in price
VAT added on top
calculations without VAT
refund estimates
affiliate commissions
other fixed selling costs
net earnings
net earnings per sale
seller-retention percentage
effective cost percentage

It also includes:

instant recalculation
fee breakdown
visual chart
predefined scenarios
shareable calculation URLs
CSV export
copyable result summaries
print-friendly output

You can test it here:

Seller Earnings Calculator

Why I published the calculation engine

Financial calculators should not behave like black boxes.

A user should be able to inspect:

which revenue base is used,
how VAT is extracted,
which amount payment fees apply to,
how refunds are estimated,
how marketplace commission is calculated,
whether intermediate values are rounded.

For that reason, I published the core TypeScript calculation engine separately from the complete esdecode application.

The public repository contains:

calculation types
input validation
the main calculation function
VAT handling
automated tests
a basic usage example
MIT license

The complete marketplace application and production interface are not included.

Repository:

github.com/esdecode/seller-earnings-calculator

TypeScript usage example

The calculation engine can be called with a typed input object:

import { calculateSellerEarnings } from "./src/index.js";

const result = calculateSellerEarnings({
  productPrice: 49,
  numberOfSales: 20,
  marketplaceFeePercent: 20,
  paymentFeePercent: 2.9,
  fixedPaymentFee: 0.3,
  vatMode: "included",
  vatRatePercent: 20,
  refundRatePercent: 0,
  affiliateFeePercent: 0,
  otherFixedCosts: 0,
  currency: "EUR",
});

console.log(result.netRevenue);
console.log(result.netPerSale);
console.log(result.sellerRetentionPercent);

The returned result includes:

{
  customerTotal,
  baseRevenueExcludingVat,
  vatAmount,
  marketplaceFee,
  paymentPercentageFee,
  paymentFixedFeeTotal,
  refundAmount,
  affiliateFee,
  otherFixedCosts,
  totalFees,
  netRevenue,
  netPerSale,
  effectiveCostPercent,
  sellerRetentionPercent
}

Validation

The engine rejects invalid inputs such as:

negative product prices
negative fixed costs
percentages below 0%
percentages above 100%
fractional sales counts
NaN
Infinity

It also handles:

zero sales
zero-price products
zero fees
negative earnings when costs exceed revenue

Negative earnings are intentionally not forced to zero.

If the seller's costs are greater than the available revenue, the result should show a loss rather than hide it.

Calculation assumptions

No public calculator can represent every marketplace and payment-provider policy automatically.

The current calculation engine uses these assumptions:

marketplace commission is calculated from revenue excluding VAT,
percentage-based payment fees are calculated from the customer total,
fixed payment fees apply once per transaction,
refunds are estimated as a percentage of customer-facing sales,
affiliate commission is calculated from revenue excluding VAT,
other fixed costs are subtracted directly,
intermediate values are not unnecessarily rounded.

Actual payouts may differ because of:

regional tax rules
currency conversions
payment-provider pricing
marketplace-specific commission rules
discounts
promotional pricing
partial refunds
non-refundable processing fees
chargebacks
payout fees
withholding taxes

This is why the calculator keeps the main fee fields configurable.

What I learned while building it

The most important lesson was that the visible marketplace commission is only one part of the seller's total cost.

A marketplace advertising a 10% commission does not necessarily mean the seller keeps 90%.

The final result may also be reduced by:

VAT
payment processing
transaction fees
refunds
affiliate payouts
currency conversion
operating costs

Another lesson was that calculation assumptions should be visible.

Two calculators can produce different results from identical inputs simply because one calculates fees from the VAT-inclusive customer total and another calculates them from revenue excluding VAT.

Without an explanation of the formula, users cannot determine which result better matches their situation.

Possible future improvements

The next versions could include:

marketplace-specific presets
payment-provider presets
country-specific VAT presets
chargeback costs
currency-conversion fees
monthly fixed expenses
annual revenue forecasting
downloadable PDF reports
side-by-side marketplace comparisons
recurring subscription revenue
tiered marketplace commissions

Marketplace presets require careful maintenance because fees can change.

Each preset should ideally include:

the source of the fee
the date it was verified
explanatory notes
whether the preset is still current

Feedback

I would be interested in hearing how other developers and digital-product sellers calculate their real earnings.

In particular:

Should marketplace commission be calculated before or after VAT?
Should refund estimates include lost payment-processing fees?
Which costs do software sellers most commonly forget?
Would marketplace-specific presets be useful?
Which additional scenarios should the calculator support?

The live tool is available here:

https://esdecode.com/tools/seller-earnings-calculator

The calculation engine and tests are available here:

https://github.com/esdecode/seller-earnings-calculator

Disclaimer

This calculator provides estimates only.

Actual payouts may differ because of marketplace policies, payment-provider rules, regional pricing, VAT treatment, currency conversion, refunds, chargebacks, and other factors.

It does not constitute legal, tax, financial, or accounting advice.

How to Audit a Laravel Script Before Buying Its Source Code

esde_site — Fri, 17 Jul 2026 12:22:22 +0000

Buying a ready-made Laravel application can save weeks or even months of development.

A billing system, booking platform, CRM, marketplace, admin dashboard, or SaaS starter kit may already include most of the functionality you need. However, screenshots and feature lists tell you very little about what maintaining the application will actually be like.

A script can look polished in a demo while containing outdated dependencies, undocumented background workers, weak authorization, hardcoded configuration, or a database structure that becomes difficult to modify.

Before buying Laravel source code, you should treat it as a technical dependency rather than a finished black-box product.

This guide explains what to inspect before making a purchase or deploying a purchased Laravel application.

1. Identify exactly what you are buying

The word “script” can describe very different products.

You may be looking at:

a complete Laravel application,
a SaaS starter kit,
an admin dashboard,
a reusable Laravel package,
a module for an existing system,
a frontend template connected to Laravel,
or a proof of concept that still requires significant development.

Before reviewing the code, establish the product’s actual scope.

Ask:

Is this a complete application or only a starter?
Is the backend fully implemented?
Is the frontend included?
Are the database migrations included?
Is authentication already configured?
Does the demo show the exact version being sold?
Which functions require third-party services?
What still needs to be developed?

A long feature list does not necessarily mean that every feature is production-ready.

For example, “payment support” may mean a completed integration with verified webhooks, or it may only mean that a checkout button exists.

The seller should clearly explain what is included and what is not.

2. Check the Laravel and PHP versions

The product listing should state the exact Laravel and PHP versions it supports.

Do not accept descriptions such as:

“latest Laravel,”
“modern PHP,”
“works with all versions,”
or “easy to upgrade.”

Laravel and PHP compatibility affects:

security maintenance,
available framework features,
package compatibility,
hosting requirements,
and the cost of future upgrades.

Inspect these files:

composer.json
composer.lock
package.json
.env.example

In composer.json, look for the PHP and Laravel requirements:

{
  "require": {
    "php": "^8.3",
    "laravel/framework": "^12.0"
  }
}

Compare the declared versions with the official Laravel documentation for the exact framework version used by the product.

Also verify that the code actually matches the declared framework version. A seller may update composer.json without adapting deprecated APIs, middleware configuration, service providers, or package integrations.

3. Inspect Composer dependencies

Third-party packages can save development time, but every package also becomes a maintenance and security dependency.

Run:

composer show --direct
composer outdated
composer audit

Look for:

abandoned packages,
packages with known vulnerabilities,
packages locked to very old versions,
private packages requiring undocumented credentials,
packages with incompatible licenses,
unnecessary packages included only for minor functionality,
and repositories loaded from unknown sources.

Pay particular attention to Composer scripts:

{
  "scripts": {
    "post-install-cmd": [],
    "post-update-cmd": []
  }
}

Installation scripts can execute commands automatically. You should understand what each script does before running composer install.

A project containing outdated dependencies is not automatically unusable, but you need to understand how difficult and risky the upgrade path will be.

4. Review the project structure

A Laravel application does not need to follow one perfect architecture, but its organization should be understandable and consistent.

Inspect:

app/
config/
database/
resources/
routes/
tests/

Warning signs include:

controllers containing hundreds or thousands of lines,
duplicated business logic,
direct database queries scattered through views and controllers,
validation repeated manually in many places,
authorization checks performed only in the frontend,
hardcoded URLs, currencies, email addresses, or credentials,
and unrelated functionality placed inside Eloquent models.

Look for sensible use of:

Form Request validation,
policies and gates,
middleware,
service or action classes,
events and listeners,
jobs,
configuration files,
database migrations,
and reusable components.

You do not need the project to follow every fashionable architecture pattern. You need it to be maintainable by someone other than the original author.

5. Verify environment configuration

A professional Laravel project should include a useful .env.example file.

It should document the configuration required for:

the application URL,
database connection,
cache,
sessions,
queues,
email,
storage,
external APIs,
payment gateways,
and other integrations.

Secrets must not be committed to the repository.

Search for common secret patterns:

git grep -n "API_KEY"
git grep -n "SECRET"
git grep -n "PASSWORD"
git grep -n "PRIVATE_KEY"

Also check that application code retrieves settings through configuration:

config('services.provider.key')

rather than calling:

env('PROVIDER_KEY')

throughout the application.

The project should never include:

a real production .env file,
active credentials,
private keys,
customer data,
or payment secrets.

6. Test the installation on a clean environment

Do not assume that an application is installable because the seller has a working demo.

A demo may be running on an environment that no longer matches the distributed package.

Install the application in a clean local, containerized, or staging environment.

A typical Laravel installation may involve:

composer install
cp .env.example .env
php artisan key:generate
php artisan migrate
php artisan db:seed
npm install
npm run build
php artisan storage:link

The exact process will vary, but it should be documented.

Check whether:

migrations run successfully on an empty database,
seeders complete without errors,
frontend assets build successfully,
uploaded files are stored correctly,
mail configuration is explained,
queues are required,
scheduled tasks are required,
and default admin credentials must be changed.

The web server should use Laravel’s public directory as the document root.

If installation requires undocumented database edits, copied vendor files, or direct code modifications, future maintenance will probably be difficult.

7. Check authentication and authorization

Authentication answers:

Who is this user?

Authorization answers:

What is this user allowed to do?

Many applications implement login correctly but fail to enforce permissions consistently.

Test whether a normal user can:

open an administrator URL directly,
modify another user’s record by changing an ID,
call protected API endpoints,
access files owned by another account,
or perform actions hidden only by the frontend.

Review:

middleware,
policies,
gates,
controller authorization,
API authorization,
ownership checks,
and role management.

Do not rely only on interface testing. A hidden button is not an authorization control.

For multi-tenant applications, verify that tenant separation is enforced in every relevant query and action.

8. Review input validation and file uploads

All untrusted input must be validated on the server.

Inspect forms and API endpoints for:

required fields,
data types,
maximum lengths,
allowed values,
numeric boundaries,
date validation,
and ownership or permission checks.

Laravel Form Request classes are useful because they keep validation and authorization rules close to the request workflow.

File uploads deserve additional scrutiny.

Check:

allowed extensions,
MIME validation,
file size limits,
filename generation,
storage location,
image processing,
authorization to download private files,
and cleanup when records are deleted.

Uploaded files should not be placed in an executable public location without adequate protection.

9. Search for unsafe output and raw queries

Blade escapes output by default:

{{ $value }}

Unescaped output uses:

{!! $value !!}

Search for unescaped output and confirm that the displayed content is trusted or sanitized:

git grep -n "{!!"

Also inspect raw database expressions and queries:

git grep -n "DB::raw"
git grep -n "whereRaw"
git grep -n "selectRaw"
git grep -n "statement("

Raw SQL is not inherently unsafe, but user-controlled values must never be concatenated directly into a query.

Pay attention to:

dynamic column names,
sorting parameters,
report filters,
search functions,
import tools,
and administrative query builders.

10. Understand queues, cron jobs, and long-running services

Some Laravel applications appear functional during a basic browser test but depend on background services for critical features.

Ask whether the application requires:

a queue worker,
Laravel Horizon,
Redis,
scheduled Artisan commands,
Laravel Reverb,
Octane,
or external process supervision.

Typical production processes may include:

php artisan queue:work
php artisan schedule:run

Check:

which queue connection is required,
how failed jobs are handled,
whether jobs can be retried safely,
whether workers need to restart after deployment,
and how scheduled tasks avoid overlapping.

Undocumented background requirements are a common reason purchased applications work locally but fail after deployment.

11. Review payment and third-party integrations

For payment, crypto, email, storage, maps, AI, SMS, or social login integrations, determine:

which providers are supported,
whether API credentials are required,
whether a sandbox mode exists,
which provider fees apply,
how webhooks are verified,
and what happens when an external service is unavailable.

For payment workflows, inspect whether:

payment status is confirmed server-side,
webhook signatures are verified,
repeated webhooks are handled safely,
transactions are idempotent,
refunds are represented correctly,
and sensitive payment details are not stored unnecessarily.

A screenshot showing a payment gateway logo does not prove that the integration is complete.

Also confirm that the product does not make unsupported claims about legal, tax, financial, healthcare, or regulatory compliance.

12. Check error handling and production configuration

The production application must not expose stack traces, SQL errors, environment values, or filesystem paths.

Verify:

APP_ENV=production
APP_DEBUG=false

Test:

invalid routes,
invalid form submissions,
failed API calls,
unavailable databases,
failed payments,
missing files,
and unauthorized actions.

Errors shown to users should be useful without revealing sensitive implementation details.

Logs should contain enough information for diagnosis without recording:

passwords,
access tokens,
payment data,
private keys,
or personal data unnecessarily.

13. Examine database migrations and data integrity

Review the database structure before deciding how easily the application can be extended.

Check:

foreign keys,
indexes,
unique constraints,
nullable fields,
decimal types for money,
timestamps,
soft deletes,
and cascading behavior.

Look for business rules that exist only in the interface but are not protected by database constraints or server-side validation.

Test migrations from a clean database and, where relevant, test rollbacks.

For an existing project, also ask how upgrades modify the database. A seller should provide migrations rather than asking buyers to import a new database dump for every update.

14. Evaluate tests and documentation

A lack of automated tests does not automatically make a script unusable, but it increases the cost and risk of modifications.

Look for tests covering:

authentication,
permissions,
critical business rules,
payments,
API endpoints,
imports,
and tenant isolation.

Run:

php artisan test

Documentation should cover more than installation.

Useful documentation includes:

architecture overview,
configuration reference,
deployment,
queue and scheduler requirements,
customization,
API usage,
upgrade instructions,
troubleshooting,
and changelog history.

Compare the documentation with the distributed code. Old screenshots and commands may indicate that documentation has not been updated with the product.

15. Read the license before purchasing

Source-code access does not automatically give you unlimited rights.

Confirm whether the license permits:

modification,
commercial use,
use in client projects,
use on multiple domains,
use in multiple products,
SaaS deployment,
resale of the resulting service,
and redistribution of the original source code.

Also inspect third-party licenses for:

Composer packages,
JavaScript packages,
fonts,
icons,
images,
themes,
and bundled commercial components.

Ask for clarification before purchasing if any essential use case is ambiguous.

Do not assume that “commercial license” means unrestricted redistribution.

16. Review the seller and update history

The code is only one part of the purchase.

Investigate:

when the product was first published,
when it was last updated,
how frequently updates are released,
whether changelog entries contain meaningful details,
whether the seller answers technical questions,
and what support includes.

Ask what happens when:

Laravel releases a new major version,
a dependency becomes vulnerable,
a payment API changes,
or a critical bug appears.

A seller does not need to promise lifetime updates, but the update and support policy should be explicit.

17. Use automated tools, but do not stop there

Automated checks are useful for identifying obvious issues.

A basic review may include:

composer validate
composer diagnose
composer audit
composer outdated

npm audit

php artisan about
php artisan test
php artisan route:list

You may also use static-analysis and formatting tools where the project supports them.

However, automated tools cannot reliably identify every problem involving:

business logic,
tenant isolation,
authorization,
payment state transitions,
workflow bypasses,
or insecure architectural decisions.

Automated scanning should be combined with manual review focused on:

authentication,
authorization,
trust boundaries,
data flows,
and security-sensitive business logic.

A practical purchase decision

Before purchasing a Laravel script, you should be able to answer:

Which Laravel and PHP versions does it support?
Can it be installed on a clean environment?
Are dependencies maintained?
Is the license suitable for the intended project?
Are authentication and authorization enforced server-side?
Are queues, cron jobs, and external services documented?
Are updates and support terms clear?
Can the code be maintained by another developer?
Have security-sensitive workflows been reviewed?
Does the seller provide enough information to verify their claims?

If several of these questions remain unanswered, do not rely on the demo alone.

Request more information, ask for documentation, or arrange an independent code review before deploying the product.

Final thoughts

Buying Laravel source code can be a sensible way to accelerate a project, but the purchase price is only part of the total cost.

The real cost also includes:

installation,
customization,
dependency upgrades,
security review,
infrastructure,
maintenance,
and future framework migrations.

A careful audit helps you determine whether you are buying a maintainable foundation or inheriting an expensive technical problem.

For a reusable review process, use the open Laravel Script Purchase and Audit Checklist.

You can also explore self-hosted Laravel scripts with full source code on esdecode.

Disclaimer: This guide does not replace a professional security audit, penetration test, legal review, or production infrastructure assessment.

A Buyer's Checklist for Testing a SaaS Boilerplate Before You Build On It

esde_site — Mon, 06 Jul 2026 09:58:08 +0000

A boilerplate is not a convenience purchase. It becomes the foundation your product is built on, and every shortcut baked into it becomes a shortcut in your product. Technical debt you inherit on day one compounds: the auth flow you didn't inspect becomes the auth flow your customers rely on, and the migration tooling you didn't check becomes the tooling you fight during your first production incident.

The goal of buying a boilerplate is to buy speed — a working signup flow, a wired-up billing integration, a sensible project structure — without buying a codebase you can't maintain. That trade-off only works if you vet the code before you commit to it.

Treat the evaluation as pre-purchase due diligence. Run it against a live demo, a trial, or read-only repository access. If a seller offers none of those, that's already useful information. What follows is a checklist you can work through in an afternoon, organized from cheap first-pass signals to the deeper code review that actually matters.

First-Pass Screening Before You Look at Code

Some signals cost you five minutes and can rule a product out before you spend an hour reading source.

Maintenance cadence. Look at the last commit or release date and the update history. A boilerplate that tracks a fast-moving framework but hasn't been touched in a year is a liability, because framework upgrades will land on you.
License terms. Read exactly what you're allowed to do. Can you use it across multiple projects? Can you resell products built on it? Licensing for purchased source code varies by seller, so don't assume — confirm in writing.
Documentation and changelog. A README with setup steps, an architecture overview, and a changelog tells you the author thinks about handoff. A public issue tracker tells you how problems get surfaced and resolved.
Stack and versions. Confirm the exact framework, language, and runtime versions it targets. "Modern React" is not a version. You want to know whether you're inheriting a current release or one that's a major version behind.

If you want a broader framework for this stage, see our guide on how to evaluate source code before buying.

Authentication and Authorization

Auth is where a weak boilerplate does the most damage, because mistakes here are security mistakes. Read the code, don't trust the feature list.

Session and token handling. Understand how the boilerplate keeps users logged in: server-side sessions, cookies, JWTs, refresh tokens, or a mix. Check how tokens are stored and how expiry and rotation are handled.
Credential handling. Verify passwords are hashed with a modern algorithm, not stored or weakly hashed. Trace the email verification and password reset flows end to end — reset tokens should be single-use and time-limited.
OAuth and MFA. If social login is advertised, check how deeply it's wired. Confirm whether multi-factor authentication is actually available or just mentioned.
Server-side authorization. Role-based access control is only meaningful if it's enforced on the server. Hiding a button in the UI is not access control. Confirm permission checks happen at the request/query layer.

The OWASP Authentication Cheat Sheet is a good reference for what secure session and password handling should look like — use it as a yardstick while reading the code.

Billing and Payments Integration

Stripe is one of the more commonly integrated providers in SaaS boilerplates, but "has Stripe" and "has production-ready billing" are different claims. The gap is in the details.

Depth of integration. Identify which provider is used and how much of the subscription lifecycle it actually covers versus a single checkout call.
Webhook handling. Subscription state should be driven by webhooks, not by optimistic client-side assumptions. Stripe recommends verifying webhook signatures so you know events genuinely originate from Stripe — check that the boilerplate does this. The Stripe webhooks documentation describes the expected pattern.
Idempotency. Billing operations can be retried. Idempotency keys prevent duplicate processing of the same event. Confirm the code handles repeated webhook deliveries without double-charging or double-provisioning.
Lifecycle edge cases. Look at how plan changes, proration, failed payments, dunning, and cancellations are handled. These are the paths that break in production, and they're the parts cheap boilerplates skip.
Tax. Determine whether tax calculation is delegated to the provider or left entirely to you. Either can be fine, but you need to know before launch.

Multi-Tenancy Architecture

If you're building B2B SaaS with organizations and teams, the tenancy model shapes everything downstream. There's no universally correct choice — it depends on your scaling and compliance needs.

Common patterns include:

Shared schema with a tenant identifier — every row carries a tenant_id. Simple and cost-efficient, but isolation depends entirely on disciplined queries.
Schema per tenant — stronger separation within one database.
Database per tenant — the strongest isolation, with the highest operational overhead.

What matters more than the label:

Isolation is enforced at the data layer. In a shared-schema model, confirm that tenant scoping is applied at the query level so one tenant can never read another's data. UI-level filtering is not isolation.
Organization modeling. Check how organizations, teams, roles, and member invitations are represented. Retrofitting a team model onto a single-user boilerplate is expensive.
Fit for your requirements. If you'll have compliance obligations that demand physical data separation, a shared-schema boilerplate may not fit no matter how clean it is.

Database Migrations and the Data Layer

How schema changes are managed determines how painful every future feature will be.

Migration tooling. Confirm there's a real migration tool in use — for example, Prisma Migrate, Drizzle Kit, Alembic, or Rails migrations — rather than hand-edited SQL applied by hand. The Prisma Migrate documentation is a good example of what versioned migrations should look like.
Versioned and reproducible. Migrations should be checked into version control, applied in a deterministic order, and reversible where the tooling allows.
Seeds and environments. Look at how seed data works and how local development differs from production configuration.
ORM and lock-in. Understand the query layer choice and how tightly your application code is coupled to it. Switching ORMs later is a large undertaking, so this is a decision you're effectively adopting.

Dependency Freshness and Security

A boilerplate's dependency tree is your dependency tree the moment you build on it.

Run a vulnerability audit locally. For Node projects, npm audit reports known vulnerabilities in the dependency tree (npm audit docs). For Python, pip-audit scans installed packages against known advisories.
Outdated or abandoned packages. Check for dependencies that are several major versions behind, unmaintained, or nearing end of life.
Surface area. Count the dependencies. A boilerplate with hundreds of transitive packages is a larger attack and maintenance surface than one that stays lean.

Test Coverage and Code Quality

Tests tell you whether the author verified their own claims — but read them, don't just read the coverage number.

Presence of automated tests. Look for unit, integration, and end-to-end tests. Their existence signals a certain level of care.
What's actually tested. Confirm that the critical paths — authentication and billing especially — are covered. A high coverage percentage does not guarantee the important logic is exercised; you can hit 90% coverage while never testing the webhook handler.
Quality tooling. Check for linting, type checking, and a CI configuration that runs tests on every change. This is a proxy for how the code will hold up as you extend it.

Upgrade Paths and Long-Term Maintainability

The purchase price is small next to the cost of maintaining the code for years.

Framework upgrades. Consider how the boilerplate is structured to absorb a major framework version bump. Tightly coupled, undocumented code makes upgrades painful.
Extension seams. The best boilerplates give you clear places to add features without forking core files. If every customization means editing shared code, merges and updates get harder over time.
Feature coupling. Try to remove a feature you don't need. If billing is entangled with auth is entangled with the dashboard, you'll carry weight you can't cut.

Running the Checklist: A Practical Workflow

A repeatable process keeps you honest and comparable across candidates.

Complete a full flow. Clone or spin up the demo and go from signup all the way to a paid subscription, including a plan change and a cancellation if possible.
Read the two paths that matter most. Trace the auth code and the billing code end to end. These are where risk concentrates.
Run the tooling locally. Execute the test suite and a dependency audit on your own machine, not just trust the README.
Score and weigh. Rate each area, then weigh those scores against what your product actually needs. A missing tax feature may be irrelevant to one founder and disqualifying to another.

Pre-Purchase Checklist

[ ] Last commit/release is recent and updates are regular
[ ] License permits your intended use (multi-project, resale if needed)
[ ] Documentation, changelog, and issue tracker exist
[ ] Exact framework, language, and runtime versions confirmed
[ ] Session/token handling inspected in code
[ ] Password hashing, email verification, and reset flows verified
[ ] OAuth and MFA support confirmed if needed
[ ] Authorization enforced server-side, not just in the UI
[ ] Billing driven by verified webhooks with idempotency
[ ] Plan changes, failed payments, and cancellations handled
[ ] Tenancy model identified and isolation enforced at the data layer
[ ] Organization/team/invitation modeling matches your needs
[ ] Versioned, reproducible migrations via a real migration tool
[ ] Dependency audit run locally with acceptable results
[ ] Automated tests exist and cover auth and billing
[ ] Linting, type checking, and CI configured
[ ] No hardcoded secrets or credentials in the repo
[ ] A clear path to upgrade the framework later

Red Flags That Should Make You Walk Away

Some findings are severe enough to end the evaluation:

No tests, no documentation, and no recent maintenance together suggest a codebase you'll be maintaining alone from day one.
Hardcoded secrets or credentials in the repository. Storing secrets in source is a recognized security risk, and finding them signals broader carelessness.
Tenant data not isolated at the data layer. In a multi-tenant product, this is a data-leak waiting to happen.
Restrictive or ambiguous licensing. If you can't tell whether you're allowed to ship your product, don't build on it. Our overview of software license types for purchased code can help you interpret the terms.

Where to Buy

Once you know how to evaluate a boilerplate, finding the right one becomes a matter of applying the same checklist to each candidate. Independent developers publish and sell starter kits through specialized marketplaces, where you can browse SaaS boilerplates and other source code products on ESDEcode. Regardless of where you buy, apply the same due diligence—the marketplace does not replace your responsibility to review the code.

Conclusion

Buying a boilerplate is buying a decision you'll live with for the life of the product. An afternoon of due diligence — completing the signup-to-paid flow, reading the auth and billing paths, running an audit, and checking the license — is cheap insurance against months of remediation. Score each candidate against your actual requirements rather than a generic ideal, and be willing to walk away when the red flags outnumber the shortcuts you can live with.

FAQ

How do I know if a SaaS boilerplate is worth buying?
Run it through the checklist above. If maintenance is recent, auth and billing paths are sound, tenancy isolation is enforced, tests cover the critical paths, and the license permits your use, it's a candidate worth the price. Weight each area against what your product actually needs.

How do I check if a boilerplate's authentication is secure?
Read the code rather than the feature list. Verify password hashing, single-use time-limited reset tokens, sensible session/token handling, and server-side authorization. Compare against the OWASP Authentication Cheat Sheet.

Is the billing integration production-ready?
Check that subscription state is driven by signature-verified webhooks, that operations use idempotency to survive retries, and that plan changes, failed payments, and cancellations are all handled. A single checkout call is not a billing system.

What multi-tenancy model should I look for?
There's no universal best. Shared schema with a tenant ID is simple and cheap; schema-per-tenant and database-per-tenant offer stronger isolation at higher operational cost. Match the model to your scaling and compliance needs, and confirm isolation is enforced at the data layer.

Does high test coverage mean the code is reliable?
No. Coverage percentage measures how much code runs during tests, not whether the important logic is meaningfully verified. Read the tests to confirm auth and billing are actually exercised.

Will I be able to upgrade the framework later?
That depends on how the boilerplate is structured. Clear extension seams and loose coupling make upgrades manageable; code that forces you to edit shared core files for every customization makes them painful. Assess this before you buy.