The answer: Multi-tenant architecture. Here's why we made that choice and what we learned along the way.

The Problem: Scaling School Management​

Imagine this scenario:

• School A has 500 students
• School B has 2,000 students
• School C has 100 students

Each school needs:

• Complete data isolation (School A can't see School B's data)
• Custom configurations (different fee structures, grading systems)
• High availability (downtime affects hundreds of students)
• Cost-effective pricing

The question: Do we deploy separate instances for each school, or build one system that serves them all?

Option 1: Single-Tenant (One Instance Per School)​

Pros:​

• Complete isolation (each school has its own database and server)
• Easier to customize per school
• One school's issues don't affect others

Cons:​

• Expensive - Each school needs its own infrastructure
• Slow onboarding - Setting up a new school takes hours/days
• Maintenance nightmare - Updates must be deployed to dozens of instances
• Inconsistent experience - Schools on different versions have different features

Verdict: This would have killed us financially and operationally.

Option 2: Multi-Tenant (One Instance, Many Schools)​

Pros:​

• Cost-effective - Shared infrastructure across all schools
• Fast onboarding - New schools start in minutes
• Easy updates - Deploy once, all schools benefit
• Consistent experience - Everyone on the same version

Cons:​

• Complex architecture - Data isolation is critical
• Performance concerns - One school's load affects others
• Security risks - A breach could affect multiple schools

Verdict: The pros outweighed the cons—if we built it right.

How We Implemented Multi-Tenancy​

1. Database Design: Shared Database, Separate Schemas​

We use a shared database with tenant isolation approach:

-- Every table has a tenant_id column
CREATE TABLE students (
    id BIGINT PRIMARY KEY,
    tenant_id BIGINT NOT NULL,  -- Links to the school
    name VARCHAR(255),
    email VARCHAR(255),
    -- ... other fields
    FOREIGN KEY (tenant_id) REFERENCES tenants(id)
);

-- Index for fast tenant-based queries
CREATE INDEX idx_students_tenant ON students(tenant_id);

Why this works:

• All data is in one database (easier to manage)
• Every query is automatically scoped to a tenant
• Impossible to accidentally query another school's data

2. Tenant Identification: Subdomain-Based​

Each school gets a unique subdomain:

• school-a.cyfamod.com
• school-b.cyfamod.com
• school-c.cyfamod.com

When a request comes in:

1. Extract subdomain from the URL
2. Look up the tenant in our tenants table
3. Set the tenant context for all subsequent queries

// Laravel middleware example
public function handle($request, Closure $next)
{
    $subdomain = $this->getSubdomain($request);
    $tenant = Tenant::where('subdomain', $subdomain)->firstOrFail();
    
    // Set tenant context
    app()->instance('tenant', $tenant);
    
    return $next($request);
}

3. Data Isolation: Global Scopes​

To prevent accidental data leaks, we use global query scopes:

// Automatically filter all queries by tenant
class Student extends Model
{
    protected static function booted()
    {
        static::addGlobalScope('tenant', function (Builder $builder) {
            $builder->where('tenant_id', app('tenant')->id);
        });
    }
}

// Now all queries are automatically scoped
$students = Student::all();  // Only returns current tenant's students

Safety net: Even if a developer forgets to filter by tenant, the global scope ensures data isolation.

4. Performance Optimization: Tenant-Aware Caching​

Caching in a multi-tenant system requires careful key management:

// Bad: Cache key collision between tenants
Cache::get('students');

// Good: Tenant-specific cache keys
Cache::get("tenant:{$tenantId}:students");

We also use:

• Database connection pooling to handle concurrent tenant requests
• Query optimization with proper indexing on tenant_id
• CDN caching for static assets

Challenges We Faced​

Challenge 1: Tenant Onboarding​

Creating a new school used to involve:

1. Manual database setup
2. Configuring subdomain
3. Setting up initial admin user
4. Importing school data

Solution: We automated everything with a tenant provisioning service:

php artisan tenant:create "St. Mary's School" --subdomain=stmarys

This command:

• Creates tenant record
• Sets up subdomain DNS
• Seeds default data (roles, permissions)
• Sends welcome email to admin

Result: Onboarding went from hours to minutes.

Challenge 2: Database Migrations​

Running migrations in a multi-tenant system is tricky:

• Do we migrate all tenants at once?
• What if a migration fails for one tenant?

Solution: Tenant-aware migration system:

# Migrate all tenants
php artisan migrate:tenants

# Migrate specific tenant
php artisan migrate:tenants --tenant=stmarys

We also implemented:

• Rollback capability per tenant
• Migration status tracking to know which tenants are on which version
• Automated backups before migrations

Challenge 3: Testing​

Testing multi-tenant features requires:

• Creating test tenants
• Ensuring data isolation in tests
• Cleaning up after tests

Solution: Test helpers for tenant management:

public function test_student_creation()
{
    $tenant = $this->createTenant();
    $this->actingAsTenant($tenant);
    
    $student = Student::create([...]);
    
    $this->assertDatabaseHas('students', [
        'tenant_id' => $tenant->id,
        'name' => $student->name,
    ]);
}

Benefits We've Seen​

1. Cost Savings​

• Before: $50/month per school (separate servers)
• After: $5/month per school (shared infrastructure)

Savings: 90% reduction in infrastructure costs

2. Faster Onboarding​

• Before: 2-3 days to set up a new school
• After: 5 minutes

Impact: We can onboard schools instantly, removing a major sales friction point.

3. Easier Maintenance​

• Before: Deploy updates to 20+ instances individually
• After: One deployment, all schools updated

Impact: We ship features faster and with less risk.

4. Better Resource Utilization​

• Small schools (100 students) share resources with larger schools (2,000 students)
• Database connection pooling reduces idle connections
• Shared caching improves performance for all tenants

Lessons Learned​

1. Security is Non-Negotiable​

Data isolation must be bulletproof. We:

• Use global scopes to prevent leaks
• Run regular security audits
• Test tenant isolation in every feature

2. Performance Monitoring is Critical​

One tenant's load can affect others. We monitor:

• Query performance per tenant
• Resource usage per tenant
• Slow queries that need optimization

3. Tenant Customization is Limited​

While we support some customization (logos, colors, fee structures), we can't offer unlimited flexibility.

Trade-off: Standardization enables scale, but limits uniqueness.

4. Backup and Recovery Must Be Tenant-Aware​

We can't restore the entire database for one tenant's issue. Our backup strategy:

• Daily full database backups
• Tenant-specific data export capability
• Point-in-time recovery per tenant

When Multi-Tenancy Makes Sense​

Multi-tenant architecture is great for:

• SaaS products serving many similar customers
• Cost-sensitive markets where pricing matters
• Rapid scaling where onboarding speed is critical

It's NOT ideal for:

• Highly customized solutions per customer
• Regulated industries requiring physical data separation
• Extremely large tenants that need dedicated resources

The Future: Hybrid Approach​

As we grow, we're considering a hybrid model:

• Small/medium schools: Multi-tenant (shared infrastructure)
• Large schools/districts: Single-tenant (dedicated infrastructure)

This gives us:

• Cost efficiency for most customers
• Dedicated resources for enterprise clients
• Flexibility to serve all market segments

Final Thoughts​

Choosing multi-tenant architecture was one of the best decisions we made for Cyfamod. It's allowed us to:

• Serve schools affordably
• Scale quickly
• Maintain high quality

But it required careful planning, robust security, and constant monitoring.

If you're building a SaaS product, consider multi-tenancy—but understand the trade-offs and build it right from the start.

Want to see our multi-tenant implementation? Check out our GitHub repository. Have questions? Join our Discord community.

But here's the thing nobody tells you: finding great people when you're a scrappy startup with limited resources is hard. Really hard.

The Reality: We're Lean (Really Lean)​

Let me be honest about our team size: we're small. Like, "everyone wears multiple hats" small.

But what we lack in numbers, we make up for in:

• Passion - Everyone believes in the mission
• Versatility - No task is "not my job"
• Ownership - Each person treats Cyfamod like their own company

How We Found Each Other​

The First Hire: A Leap of Faith​

Our first team member wasn't someone with a perfect resume. They were someone who:

• Understood the problem we were solving
• Asked smart questions about our approach
• Showed up with ideas, not just skills

Lesson learned: Hire for attitude and aptitude, not just experience. Skills can be taught; passion and drive cannot.

The Developer Who Saved Us​

We needed a backend developer. Our budget? Let's just say it wasn't competitive with big tech.

We found someone who:

• Was excited about open source
• Wanted to build something meaningful
• Valued equity and growth over a big salary

They've since become our technical backbone. Not because they knew everything, but because they were willing to learn everything.

The Designer Who "Got It"​

Finding a designer who understood both aesthetics and user experience was crucial. Schools need software that's beautiful AND functional.

We found ours through:

• Open source contributions (they'd designed for other projects)
• A shared belief in accessible design
• A portfolio that showed they could make complex systems simple

What Makes Our Team Special​

1. We're Brutally Honest​

No sugarcoating. If something isn't working, we say it. If someone's struggling, we help.

This transparency has saved us from:

• Building features nobody wants
• Letting small problems become big ones
• Burning out in silence

2. Everyone Owns Something​

We don't have "managers" and "workers." We have owners:

• Someone owns the student management module
• Someone owns the fee tracking system
• Someone owns the parent communication features

Ownership creates accountability and pride in work.

3. We Celebrate Small Wins​

Launched a new feature? We celebrate.
Fixed a critical bug? We celebrate.
Got positive feedback from a school? We celebrate.

In a startup, you can't wait for the "big win" to feel accomplished. Small wins keep morale high.

4. We Protect Each Other's Time​

With a lean team, burnout is a real threat. We've implemented:

• No meetings after 4 PM
• "Deep work" blocks where interruptions are forbidden
• Mandatory time off (yes, mandatory)

A burned-out team ships nothing.

The Challenges of Being Lean​

Let's not romanticize it—being lean is hard:

Wearing Too Many Hats​

Our backend developer also handles DevOps. Our designer also does user research. I (the founder) also do customer support.

It's exhausting. But it's also taught us to prioritize ruthlessly.

Knowledge Silos​

When only one person knows how something works, that's a risk. We combat this with:

• Pair programming sessions
• Comprehensive documentation
• Cross-training on critical systems

Imposter Syndrome​

When you're a small team competing with established players, doubt creeps in. "Are we good enough?"

We remind ourselves: We're not trying to be them. We're trying to be better for our users.

What We Look For in New Team Members​

As we grow (slowly), here's our hiring philosophy:

Must-Haves:​

1. Self-starters - We can't hold hands; we need people who figure things out
2. Communicators - Remote work requires over-communication
3. Mission-aligned - You have to care about improving education
4. Humble learners - Nobody knows everything; everyone should want to learn

Nice-to-Haves:​

1. Experience with our tech stack (Next.js, Laravel)
2. Previous startup experience
3. Open source contributions
4. Education sector knowledge

Notice the order? Attitude over aptitude, always.

Lessons Learned​

1. Culture is Built, Not Declared​

We don't have a fancy "culture deck." Our culture emerged from:

• How we treat each other during crises
• What we celebrate and what we criticize
• Who we choose to work with

2. Diversity of Thought Matters​

We're a small team, but we're diverse in:

• Technical backgrounds (frontend, backend, design, product)
• Life experiences
• Problem-solving approaches

This diversity makes us stronger.

3. Equity is Powerful​

Everyone on our team has equity. When Cyfamod succeeds, we all succeed.

This alignment of incentives has created a team that thinks like owners, not employees.

4. Remote Can Work​

We're a distributed team. It's not perfect, but it's allowed us to:

• Hire the best people, regardless of location
• Reduce overhead costs
• Offer flexibility that big companies can't match

To Future Team Members​

If you're reading this and thinking about joining a startup like ours, here's what you should know:

It won't be easy. You'll work harder than you ever have.
It won't be glamorous. You'll do tasks "beneath" your title.
It won't be stable. Startups are inherently risky.

But if you want:

• Impact - Your work will directly affect thousands of students
• Growth - You'll learn more in a year than most do in five
• Ownership - Your ideas will shape the product
• Purpose - You'll build something that matters

Then maybe we're the team for you.

Final Thoughts​

I didn't set out to build the "perfect" team. I set out to build a team that could build Cyfamod.

What I ended up with is better than I could have imagined:

• People who challenge me
• People who cover my weaknesses
• People who believe in the mission as much as I do

We're lean. We're scrappy. We're not perfect.

But we're exactly the team Cyfamod needs.

Interested in joining our journey? Check out our GitHub or reach out on Discord. We're always looking for passionate people who want to make education better.

The Beginning: A Problem Worth Solving​

It all started with a simple observation: schools in our region were drowning in paperwork. Student records scattered across Excel sheets, fee tracking done manually, and communication between teachers and parents happening through endless WhatsApp messages.

We knew there had to be a better way.

The MVP Phase: Learning to Build Fast​

Our first version was... let's just say "functional." We built it quickly, focusing on the core features schools absolutely needed:

• Student enrollment
• Basic fee tracking
• Simple grade management

The reality check: Schools wanted everything. Attendance tracking, timetable management, parent portals, SMS notifications—the list was endless.

We had to learn to say "not yet" while keeping our vision clear.

The Pivot Moments​

Multi-Tenancy: Our Game Changer​

Initially, we thought each school would need its own deployment. Wrong. The infrastructure costs would have killed us, and schools wanted to start immediately—not wait for complex setups.

Switching to a multi-tenant architecture was scary. We had to rebuild significant portions of the system, but it was the best decision we made. Now schools can sign up and start using the system within minutes.

Going Open Source​

This was controversial within our team. "Why would we give away our code for free?"

But here's what we learned: transparency builds trust. Schools are entrusting us with their most valuable data—student information. Being open source shows we have nothing to hide and invites the community to make the product better.

The Lows: When Everything Feels Impossible​

There were days when nothing worked:

• A critical bug that wiped test data (thank God for backups)
• A school threatening to leave because a feature wasn't ready
• Sleepless nights wondering if we'd make payroll

The truth nobody tells you: Building a SaaS is lonely. You're solving problems nobody else understands, making decisions with incomplete information, and constantly questioning if you're on the right path.

The Highs: Why We Keep Going​

But then there are moments that make it all worth it:

• The first school that paid for an annual subscription
• A teacher telling us we saved her 10 hours a week
• Seeing students check their results online instead of traveling to school
• Our first 5-star review

These moments remind us why we started.

What We've Learned​

1. Start Small, Think Big​

We launched with 3 core features. Now we have 20+. But we only added them when schools actually needed them, not when we thought they might.

2. Listen to Users, But Don't Build Everything They Ask For​

Every school has unique needs. If we built every requested feature, we'd have an unusable mess. We learned to identify patterns—features multiple schools need—and prioritize those.

3. Technical Debt is Real​

That "quick fix" you implement at 2 AM? It will haunt you. We've spent entire sprints refactoring code we rushed in the early days.

4. Community Matters​

Going open source brought us contributors, bug reports, and feature ideas we never would have thought of. The community has made Cyfamod better than we could alone.

The Road Ahead​

We're not done. Not even close. There's still so much to build:

• Computer-Based Testing (CBT) - just launched!
• Advanced analytics for school administrators
• Mobile apps for parents and students
• Integration with payment providers

But we're no longer scared of the journey. We've learned to embrace the rollercoaster—the ups, the downs, and the unexpected loops.

Advice for Aspiring SaaS Founders​

If you're thinking about starting a SaaS:

1. Solve a real problem - Not one you imagine, but one you've witnessed
2. Talk to users constantly - Build with them, not for them
3. Ship fast, iterate faster - Perfect is the enemy of done
4. Find your tribe - Surround yourself with people who believe in the vision
5. Take care of yourself - Burnout is real, and it helps no one

Final Thoughts​

Starting Cyfamod has been the hardest thing I've ever done. It's also been the most rewarding.

Every school we onboard, every student whose life we make a little easier, every teacher who gets their evenings back—that's why we do this.

The rollercoaster isn't slowing down. And honestly? We wouldn't have it any other way.

Are you building a SaaS or thinking about starting one? I'd love to hear your story. Connect with us on Discord or check out our GitHub.