Choosing between a SaaS boilerplate and building from scratch is not a question of whether your team is capable. It is a decision about where engineering time creates an advantage.
Authentication, billing webhooks, organization membership and transactional email are important. They are rarely the reason a customer buys your product. Your workflow, domain knowledge and distribution are more likely to matter.
The real 2026 cost therefore has three parts:
- The cash you spend on code or services
- The engineering time required before and after launch
- The opportunity cost of delaying customer feedback
The three realistic paths
Most teams are not choosing between a finished boilerplate and an empty text file. They are choosing among three paths.
| Path | You receive | You still own | Main risk |
|---|---|---|---|
| Starter kit | Working SaaS foundation and full source | Product workflow, branding, deployment and validation | The kit may not match your architecture |
| Custom implementation on a foundation | Foundation plus agreed product implementation | Product decisions, acceptance and continued operation | Scope can grow beyond the initial engagement |
| Build from scratch | Complete architectural freedom | Every integration, edge case, test and operational decision | Foundation work delays differentiated value |
There is no universally correct path. The cheapest license can be expensive if you spend weeks removing its assumptions. A custom build can be efficient when it converts a clear specification into a launchable product. Building from scratch can be correct when the infrastructure itself is the product.
What “from scratch” really includes
Starting with Next.js does not mean starting with nothing. You will use open-source packages and hosted services. The work is integrating those pieces into one reliable product.
A typical B2B SaaS foundation may need:
- email and password authentication
- social sign-in and account linking
- verification, recovery and session management
- organizations, invitations and roles
- Stripe Checkout, subscriptions and one-time payments
- webhook verification, retries and idempotency
- customer billing management and entitlements
- transactional email templates and delivery
- account, organization and security settings
- an administrator view for customer support
- environment validation, deployment and monitoring
- tests for the failure paths between these systems
Each individual feature is understandable. The cost appears at the boundaries. What happens when a webhook arrives twice? Can a removed organization member still access cached data? Does a changed subscription update entitlements before the customer returns to the dashboard? Can support diagnose the account without editing the database manually?
Calculate engineering cost without invented timelines
Marketing comparisons often assign a universal number of weeks to authentication or billing. That is not credible without knowing the team and requirements.
Use a requirements-based estimate instead:
engineering cost = estimated hours × loaded hourly cost
launch cost = engineering cost
+ tools and infrastructure
+ review and rework allowance
+ opportunity cost of delayed validation“Loaded hourly cost” is not only salary. For an employee it can include employment costs, equipment and management. For a founder it is the value of the best alternative use of that time. For an agency it is the rate charged for the work.
Build a worksheet before choosing:
| Workstream | Required for launch? | Build hours | Starter adaptation hours | Owner |
|---|---|---|---|---|
| Authentication | Yes | Your estimate | Your estimate | Backend |
| Organizations and access | Maybe | Your estimate | Your estimate | Backend |
| Billing and webhooks | Yes | Your estimate | Your estimate | Backend |
| Product data model | Yes | Your estimate | Your estimate | Product team |
| Core customer workflow | Yes | Your estimate | Your estimate | Product team |
| Admin and support tooling | Maybe | Your estimate | Your estimate | Full stack |
| Deployment and monitoring | Yes | Your estimate | Your estimate | Platform |
| Documentation and handoff | Yes | Your estimate | Your estimate | Team |
Estimate both columns honestly. A starter kit does not reduce the product data model or core workflow to zero. It should reduce work only where it already contains a suitable implementation.
What Achromatic actually includes
Achromatic provides two standalone Next.js 16 repositories with the same SaaS capabilities. One uses Prisma and one uses Drizzle. The current foundation includes:
- Better Auth with email and password, Google sign-in and two-factor authentication
- organizations, invitations, roles and member management
- Stripe subscriptions, one-time payments, per-seat billing and prepaid credits
- billing webhooks, paywalls and customer self-service
- tRPC with React Query for typed application data
- transactional email templates
- account and organization settings
- administration for users, organizations, subscriptions and credit balances
- reusable dashboard and marketing components
- testing, documentation and deployment guidance
The license provides full source for both current repositories, lifetime updates, unlimited projects under the license terms and access for developers working on the licensed team. Review the Prisma documentation, Drizzle documentation, pricing and license before treating any feature as a saved workstream.
What a starter kit does not buy
A boilerplate is a foundation, not a completed company. You still need to define and implement:
- the customer problem and product workflow
- the domain-specific database model
- your onboarding and activation path
- brand, copy and interaction design
- product-specific integrations
- analytics events and success metrics
- privacy, compliance and operational policies
- deployment configuration for your accounts
- sales, distribution and customer support
The right expectation is not “launch without development.” It is “stop implementing generic infrastructure before beginning product development.”
Compare the cash paths
Buy the source and build the product
This path has the smallest initial cash purchase. It works best when you or your team can read the code, configure external services and build the unique workflow.
The economic question is simple:
break-even hours = license price ÷ loaded hourly costIf the useful code saves more time than the break-even hours plus the time required to learn it, buying is economically rational. Do not count features you plan to delete.
Hire Achromatic to build on the foundation
The custom SaaS development service starts at $8,000 USD. A starting engagement can include product discovery, technical planning, a Prisma or Drizzle foundation, interface customization, authentication, organizations, billing configuration, one defined product workflow, deployment and source-code handoff.
The exact scope and timeline are confirmed before work begins. Complex AI systems, native mobile applications, marketplaces, legacy migrations, custom design systems and compliance-heavy products require separate scoping.
This path makes sense when the requirements are clear but the buyer does not want to staff the implementation. It does not make sense when product discovery is still so open-ended that no bounded workflow can be defined.
Build the foundation internally
Internal development avoids a license and gives the team full architectural authorship. Its cost is the time spent specifying, integrating, testing and maintaining the foundation.
This is often the right decision when:
- authentication, billing or infrastructure is the product
- a regulated environment requires controls the kit does not implement
- an existing platform already owns these capabilities
- the team has mandatory architecture or provider standards
- learning the implementation is the purpose of the project
Include risk in the estimate
An hourly comparison misses the cost of failures. Add explicit allowance for high-risk boundaries:
Authentication
Account linking, session invalidation, password recovery and authorization failures affect user access. A working sign-in screen is not a complete authentication implementation.
Billing
Payment state changes asynchronously. Test duplicated events, delayed events, failed renewals, canceled subscriptions and access restoration. The checkout page is the easy part.
Multi-tenancy
Every organization-owned query needs an authorization boundary. Test role changes, removed members, invitation expiry and switching between organizations.
Operations
Someone must investigate failed email, stale billing state and customer access. Admin tools and readable logs reduce support cost after launch.
A practical decision test
Choose a starter kit when most of these statements are true:
- the current stack matches your team's preferences
- the included features are required by your launch scope
- your product advantage sits above the foundation
- you can evaluate and maintain full-source TypeScript code
- reaching customer feedback sooner is valuable
Choose custom development when:
- you have a bounded product workflow and budget
- you want source ownership without staffing the first implementation
- the existing foundation is a strong fit
- you can make product decisions and review delivered work
Build from scratch when:
- the kit's assumptions create more removal work than saved work
- the infrastructure is strategically differentiating
- mandatory constraints conflict with the available architecture
- time-to-market is less important than internal standardization or learning
The honest conclusion
A SaaS boilerplate is worth buying only for code you would otherwise need to implement. Custom development is worth buying only when the scope is clear enough to price and accept. Building from scratch is worth the time only when the control or knowledge gained matters to the product.
Write down the required workstreams, estimate both implementation paths and include the cost of delayed feedback. The best decision is the one that directs the most time toward a customer problem rather than the one with the smallest visible invoice.