DEV Community: Clark Pesa

I Didn't Start in Marketing. Here's How I'm Learning Growth Marketing From Scratch.

Clark Pesa — Tue, 15 Sep 2026 07:43:09 +0000

I didn’t start my career in marketing.

My background is mostly in customer support, operations, administrative work, and working with clients.

For a long time, I thought marketing was mostly about content.

Create a post.

Get some traffic.

Get people to notice the product.

Repeat.

Then I started working in growth marketing.

And I realized I was wrong.

Growth marketing is much more about understanding why people do what they do.

Why do they click?

Why don’t they?

Why do they sign up?

Why do they leave?

Why does one message resonate with one person but completely miss another?

And sometimes, you don’t even have enough data to answer those questions directly.

That’s probably been the biggest adjustment for me.

Coming From Customer-Facing Work Changed How I Look at Marketing

One advantage I didn’t realize I had was my background in customer-facing roles.

When you spend enough time talking to customers, you start noticing something:

People don’t always describe their problems using the language companies use to market to them.

A company might say:

“Our platform improves operational efficiency.”

A customer might say:

“I’m wasting three hours fixing this every week.”

Those are technically talking about the same problem.

But they don’t feel the same.

That’s something I’ve started paying much more attention to in marketing.

Not just what problem exists, but how people actually describe it.

The words customers use can tell you a lot about what your messaging should sound like.

I Stopped Asking “What Should We Post?”

This was probably one of the biggest mindset changes for me.

The easy question is:

“What should we post this week?”

But that’s not always the best question.

A better one is:

“What are people already struggling to understand?”

That’s a completely different starting point.

Instead of beginning with a content format, you begin with a problem.

Then you can decide whether the answer should be a LinkedIn post, an article, a comparison page, a community reply, a forum discussion, or something else.

The format becomes secondary.

The problem comes first.

Analytics Are Useful, but They Don’t Tell You Everything

I’ve also learned that numbers can be both helpful and misleading.

You can look at impressions, reactions, page views, traffic, clicks, and other metrics.

But a number doesn’t always tell you why something happened.

A post can get a lot of impressions and create almost no meaningful interest.

Another post can get relatively few views but attract one person who asks a very specific product question.

Which one is more valuable?

It depends on what you’re trying to accomplish.

That’s why I’ve become more interested in combining quantitative signals with qualitative ones.

Analytics can tell you what happened.

Conversations can sometimes tell you why.

Community Is a Different Kind of Research

One of the things I’m enjoying most about growth marketing is observing how people talk about problems in communities.

Places like Reddit, Product Hunt, and other online communities can reveal something that polished marketing pages often don’t:

People speak differently when they’re not being marketed to.

They complain.

They compare.

They ask for alternatives.

They explain what they tried.

They tell people what they hated.

They tell people what they wish existed.

And sometimes, those conversations contain better marketing insights than a keyword spreadsheet.

Not because analytics aren’t useful.

But because people are giving you context.

I’m Also Learning That Growth Marketing Is Messy

This is probably the least glamorous part.

You don’t always have perfect attribution.

You don’t always know which activity caused a result.

Sometimes you try something and nothing happens.

Sometimes something performs better than expected and you don’t fully understand why.

Sometimes you have five possible things you could work on and no obvious answer about which one matters most.

That’s where I’m learning to get more comfortable with experimentation.

Make a reasonable hypothesis.

Do something small.

Measure what you can.

Look at what happened.

Learn.

Then adjust.

It’s less about finding the perfect answer and more about getting better answers over time.

I’m Still Figuring It Out

I don’t consider myself someone who has “mastered” growth marketing.

I’m still learning.

I’m still figuring out how SEO, content, distribution, customer research, analytics, product marketing, and community all connect.

But I think that’s also what makes the field interesting.

The more I learn, the more I realize that growth isn’t just about getting more people to see something.

It’s about understanding people better.

Understanding their problems.

Understanding what they care about.

Understanding what makes them trust something.

And understanding what makes them take the next step.

That’s a very different way of thinking about marketing.

And I’m still learning how to get better at it.

Maybe that’s the most interesting part of starting over in a new field:

You get to realize how much you still don’t know.

And then you get to start figuring it out.

How Agencies Should Evaluate a Website Builder for 10+ Client Sites

Clark Pesa — Sun, 13 Sep 2026 23:44:56 +0000

The website builder that works for your first client might not be the right one for your tenth.

When you're starting a web design agency, choosing a website builder is usually about speed, design flexibility, and how quickly you can launch a website.

But once you're managing 10 or more client sites, the decision becomes different.

You’re no longer just building websites. You’re managing a growing portfolio of businesses, each with its own content, branding, deadlines, maintenance requests, and expectations.

A platform that feels convenient for one client can become expensive, difficult to manage, or frustrating for your team at scale.

So how should agencies evaluate a website builder when they have 10+ client sites to manage?

The answer is to stop evaluating website builders like a designer choosing a tool for one project.

Instead, evaluate them like an operator building a repeatable system for delivering and maintaining websites.

Here are the factors that matter most.

1. Start With the Real Cost of Managing 10+ Websites

One of the biggest mistakes agencies make is looking at the monthly price of a website builder and assuming that's the total cost.

It isn't always.

The advertised subscription might only cover the website itself. Your actual cost could also include:

Additional websites or site plans
Team member seats
Hosting
Premium plugins or extensions
Backup services
Security tools
Third-party integrations
Extra storage
Developer time
Client support

When you multiply these expenses across 10, 20, or 50 clients, the difference becomes significant.

Calculate your portfolio cost

Instead of asking:

How much does this website builder cost per month?

Ask:

How much will it cost our agency to operate 10 client websites for an entire year?

A simple calculation:

Total annual platform cost = Site subscriptions + Team costs + Add-ons + Hosting + Maintenance overhead

For example, imagine an agency manages 10 client websites.

If each website requires $20 per month in platform and hosting costs:

10 × $20 × 12 = $2,400 per year

That is before considering additional tools, staff time, or unexpected expenses.

The number is only an illustration, but the principle is important: evaluate the cost of the entire portfolio, not just one website.

What to ask the provider

Does the plan include multiple live websites?
Are there limits on the number of sites?
Are team seats charged separately?
Are hosting and SSL included?
Are there additional charges for storage or traffic?
Can we upgrade individual sites without upgrading everything?
Does the cost remain reasonable as our client portfolio grows?

A good platform should make your costs predictable enough to plan your margins.

2. Evaluate Multi-Site Management, Not Just the Website Editor

A beautiful editor is useful.

But if your agency manages 15 client sites, the editor is only one part of the workflow.

You also need to think about what happens before, during, and after the build.

Can your team easily identify which sites are active?

Can you tell which clients are waiting for content?

Can you manage updates without jumping between disconnected tools?

Can you onboard a new client without rebuilding your entire process?

These questions matter because agencies don't just create websites. They operate websites.

Look for a centralized workflow

Ideally, your platform should make it easy to:

View and organize client projects.
Separate each client's content and access.
Manage websites across different projects.
Reuse proven layouts and components.
Collaborate with your team.
Publish updates efficiently.
Maintain sites after launch.

Not every website builder offers the same level of centralized management.

Some are designed primarily for individual websites. Others are built with agencies and multiple projects in mind.

The right choice depends on how your agency works, but the question remains the same:

Can this platform support our entire client portfolio without creating unnecessary administrative work?

3. Check Whether the Platform Supports Repeatable Delivery

This is where agencies can gain a real advantage.

Imagine you build a website for a local service business.

The next month, you sign another client in a similar industry.

Both clients need:

A homepage
About page
Services page
Contact page
Testimonials
Blog or content section

If your team starts every project from scratch, you're repeating work that could have been standardized.

That doesn't mean every client website should look identical.

It means the underlying process should be repeatable.

What can be standardized?

Depending on the platform, your agency might be able to reuse:

Page structures
Design systems
Typography settings
Navigation patterns
Content models
Form layouts
Common components
SEO checklists
Publishing workflows

A reusable system lets your team spend less time rebuilding basic infrastructure and more time improving the things that make each client unique.

Ask these questions

Can we create reusable templates?
Can we reuse components across projects?
Can we establish a consistent content structure?
Can we maintain brand differences without rebuilding everything?
Can a new team member follow the same workflow?

The goal is not to make every website identical.

The goal is to make the process of building websites more efficient.

4. Look Beyond Pages and Posts

Many agencies start with simple brochure websites.

A homepage, a few service pages, a contact form, and maybe a blog.

That works for many businesses.

But as clients grow, their content requirements often become more complicated.

A client might need:

A directory of locations
A list of team members
A portfolio of projects
A library of case studies
A catalog of products
A collection of events
A database of resources

At this point, forcing everything into ordinary pages and blog posts can become difficult.

The importance of structured content

A website builder should be evaluated based on how well it handles the type of content your clients actually need.

For example, a portfolio website might require a collection of projects.

Each project could have:

Project name
Client name
Industry
Description
Images
Services provided
Completion date

If every project is built as a manually formatted page, maintaining consistency can become harder.

A platform that supports structured or custom content can make it easier to manage information in a consistent way.

This is particularly important for agencies serving clients with growing content libraries.

Ask the provider

Can we create custom content types?
Can we add fields beyond standard pages and posts?
Can structured content be reused across templates?
Can clients manage content without editing the entire layout?
Can the platform support larger content collections?

The more varied your client projects become, the more important this flexibility is.

5. Evaluate Client Handoffs Before You Sign Up

A website isn't finished just because it has been launched.

At some point, your client will probably need to update something.

They may want to:

Change a business description
Add a new service
Upload a blog post
Update a team member
Change contact information
Add a new image

If every small change requires a developer, your agency can end up spending valuable time on routine content updates.

That can create unnecessary support costs for both you and your client.

What does a good handoff look like?

A good handoff should give the client enough control to manage their website without accidentally breaking important parts of the design.

The exact setup depends on the platform and the client's needs.

But you should consider:

Client access

Can the client log in and manage their content?

Permissions

Can you control what the client is allowed to change?

Ease of use

Can a non-technical client understand the editing experience?

Training

Can your team explain the workflow without creating a long technical manual?

Ownership

What happens if the client decides to leave your agency?

A website builder may be powerful, but if the client cannot comfortably use it, the handoff process becomes a problem.

6. Check Hosting, Security, and Performance

Managing 10+ websites means managing 10+ potential sources of technical problems.

A slow website can frustrate visitors.

A broken integration can affect lead generation.

A security issue can damage client trust.

A hosting problem can create an urgent support request.

That's why agencies should evaluate the technical infrastructure behind the website builder.

Important areas to review

Hosting

Is hosting included? Where are the websites hosted? Are there traffic or storage limitations?

Security

Does the platform provide SSL, security updates, access controls, and other relevant protections?

Performance

How does the platform handle page loading, image optimization, caching, and content delivery?

Backups

Are backups available? How does recovery work if something goes wrong?

Reliability

What support is available when a client website experiences an issue?

Don't rely on marketing claims alone

The fastest way to evaluate a platform is to test it.

Build a sample site.

Add images.

Create content.

Publish it.

Test it on mobile.

Check how the editing experience feels.

If possible, test a realistic client workflow instead of only looking at a polished demo.

The goal is to understand how the platform behaves in real agency operations.

7. Compare SEO Capabilities With Your Clients' Needs

SEO is important for many agency websites.

But SEO requirements vary depending on the client.

A local service business may need strong local search visibility.

An e-commerce business may need product pages and structured information.

A content-heavy website may need a flexible publishing system.

A professional services company may need landing pages and clear site architecture.

Your website builder should support the SEO work your agency actually delivers.

Things to evaluate

Page titles and meta descriptions
URL structure
Image optimization
Mobile performance
XML sitemaps
Robots.txt controls
Canonical URLs
Redirect management
Structured data options
Analytics and search integrations

Not every client needs every feature.

But if your agency works with different types of businesses, you should understand the platform's limitations before committing to it.

A builder that works well for a simple brochure site may not be the right fit for a complex content-driven project.

8. Make Sure Your Team Can Work Together

When you have one client, one person might handle everything.

At 10+ sites, your agency may have:

Designers
Developers
Content writers
SEO specialists
Project managers
Account managers

This makes collaboration more important.

You need to know who can access what, who is responsible for changes, and how the team handles approvals.

Questions to ask

Can multiple team members access projects?
Are permissions available?
Can clients have separate access?
Can the team review changes before publishing?
Can you separate client content from internal work?
Is there a clear process for approvals?

A good workflow reduces confusion.

It also helps prevent the classic agency problem:

Who changed this, and why is the website broken?

The platform should support your team's responsibilities instead of making everyone share the same login.

9. Evaluate the Platform's Flexibility as Your Agency Grows

Your agency may start with 10 websites.

Then 20.

Then 50.

The website builder you choose should be evaluated against your expected growth.

This doesn't mean you need the most expensive enterprise platform on day one.

It means you should understand what happens when your needs change.

Consider your growth path

At 10 websites

You may be focused on cost, organization, and repeatable delivery.

At 25 websites

You may need better client management, permissions, and standardized workflows.

At 50+ websites

You may need more advanced governance, support, monitoring, and cost controls.

The platform should not force you to completely rebuild your agency's workflow every time you add more clients.

Ask these questions

What happens when we add 10 more websites?
Can we upgrade without migrating everything?
Can we manage different client requirements?
Will our team need additional tools?
Are there limits that become expensive at scale?

Choose a platform based on where your agency is going, not just where it is today.

10. Run a Real Agency Test Before Making a Decision

A free trial or product demo is useful.

But it should not be the only thing you use to evaluate a website builder.

The best way to compare platforms is to run the same realistic scenario on each one.

A simple test

Choose a typical client project.

For example:

A local business that needs a five-page website, a contact form, a blog, and a content editor.

Then test the following workflow:

Step 1: Build the website

How long does it take to create the basic structure?

Step 2: Add content

Can you create the pages and content types you need?

Step 3: Apply branding

Can you customize the design without excessive work?

Step 4: Invite a team member

Can someone else review or edit the project?

Step 5: Test the client experience

Can a non-technical user update content?

Step 6: Publish

Is the launch process straightforward?

Step 7: Repeat

Can you use the same process for a second client?

This final step is important.

A platform might be easy to use once but difficult to use repeatedly.

For an agency, repeatability is part of the product.

A Practical Website Builder Evaluation Checklist

Before committing to a platform, use this checklist.

Category	Questions to Ask
Cost	What will 10+ sites cost annually?
Multi-site management	Can we manage multiple client sites efficiently?
Templates	Can we reuse layouts and components?
Content management	Can we support different client content requirements?
Client access	Can clients manage their own content?
Permissions	Can we control access by role?
Hosting	Is hosting included?
Security	What protections are provided?
Performance	Does the platform support fast, reliable websites?
SEO	Can we manage the SEO requirements of our clients?
Collaboration	Can our team work together efficiently?
Scalability	What happens when we reach 25 or 50 sites?
Support	Can we get help when something goes wrong?
Handoff	Can we transfer or maintain client ownership appropriately?

You can score each category from 1 to 5.

But don't just choose the platform with the highest score.

Pay attention to the categories that matter most to your agency.

A design-focused agency may prioritize creative flexibility.

A high-volume agency may prioritize cost and repeatability.

An agency working with complex content may prioritize CMS flexibility.

The right platform depends on your business model.

What About SGEN?

For agencies evaluating website builders, it's worth looking at platforms that combine website building, hosting, and content management in one system.

SGEN is one example of this approach.

SGEN positions itself as an alternative to traditional WordPress-based workflows, bringing website building, hosting, and content management together.

For agencies, the appeal of an all-in-one platform is the opportunity to reduce the number of separate tools involved in delivering and maintaining client websites.

Instead of managing a website builder, hosting provider, and multiple add-ons separately, an agency can evaluate whether a unified platform fits its workflow.

SGEN also focuses on structured content and native functionality, which can be relevant for agencies building websites with more than basic pages and blog posts.

However, the important question isn't whether a platform sounds good.

It's whether it works for your agency.

Before choosing SGEN or any other website builder, test the platform against your actual requirements.

Can it support your client sites?

Can your team use it efficiently?

Can your clients manage their content?

Does the pricing make sense at your portfolio size?

Those are the questions that should drive your decision.

Final Thoughts

Choosing a website builder for 10+ client sites is not simply a design decision.

It's an operational decision.

The wrong platform can create unnecessary costs, repetitive work, difficult handoffs, and technical headaches.

The right platform can help your agency build a more consistent process, serve more clients, and spend less time managing avoidable complexity.

When evaluating a website builder, look beyond the editor.

Evaluate:

The real cost of your entire portfolio.
Multi-site management.
Repeatable delivery.
Content flexibility.
Client handoffs.
Hosting and security.
SEO capabilities.
Team collaboration.
Long-term scalability.

Most importantly, test the platform with a real agency workflow.

Because the best website builder for your first client is not necessarily the best website builder for your tenth.

Choose the platform that helps your agency operate better, not just build faster.

How Agencies Should Evaluate a Website Builder

Clark Pesa — Wed, 02 Sep 2026 02:55:49 +0000

Most website builder evaluations happen at the worst possible moment: while you are building the first site on it.

At that moment, the platform is on its best behavior. Empty canvas, excited client, and every builder on the market feels fine when you are running one of anything.

You ship. The client is happy. You conclude the tool is good.

Then eight months pass.

You have eleven client sites. Three are on a plan tier you no longer remember choosing. One has a plugin that has not been updated since spring. A client emailed asking to change a phone number and you had to log in as them because there was no safe way to give them access to only that.

Your Tuesday now has a standing two-hour block called "site stuff."

Nothing broke.

You built an operation on a tool you evaluated as a design product.

So the question worth answering before you commit a client roster is not:

Can I build a good site on this?

Almost certainly you can.

The better question is:

What does my week look like when there are twenty of them?

1. Multi-site management: what does the second site cost you in attention?

The first thing to test is not a feature. It is a shape.

At ten client sites, where do you see them?

One place that lists all of them, or ten islands with their own logins, dashboards, and update states you have to check individually?

The follow-up questions matter more than they sound:

Can you see the state of every site without opening every site?
Does adding a client add an entire workflow, or simply add another site to manage?
Can a team member access three client sites without accessing all twenty?
What is the administrative overhead per client per month, and does it stay flat or climb?

Some platforms answer this with a portfolio or multi-site dashboard.

Others assume one site per account and expect you to add a third-party management layer.

Both can work.

They are not the same amount of work, and the difference compounds with every client you sign.

2. Repeatable delivery: how much of the last project survives into the next one?

Agencies do not become more efficient simply by building faster.

They become more efficient when proven work can be reused instead of recreated.

So look at what the platform lets you carry forward.

Staging

Can you build and revise somewhere that is not the client's live site?

Is staging a real environment, or a copy you have to keep synchronized manually?

Reusable structure

When you get a service-page layout right, can it become the starting point for the next client?

Or does every project begin from a blank canvas plus your memory of what worked last time?

Components and templates

Can proven patterns be reused?

Or is every instance another independent copy that can eventually drift?

Setup work

How much of a new project is actual design and development?

And how much is reconfiguring the same settings you configured for the previous client?

The useful measure here is not simply speed.

It is variance.

A repeatable process means the tenth site can follow a proven workflow instead of becoming another custom operational problem.

3. Client access and handoff: launch is the middle of the workflow, not the end

The site goes live.

Then the client wants to update their hours.

Swap a photo.

Add a staff member.

Publish a new page.

Now you have a permanent access decision.

Before choosing a platform, ask:

What is the least access that still lets a client do what they need?
Can you prevent them from reaching layout, settings, integrations, or billing?
If something goes wrong, is there a record of who changed what?
How do you support the client afterward?
Do you need their password?
When ownership transfers, what actually moves?

Password sharing is a useful warning sign.

If your support workflow requires storing or repeatedly requesting client credentials, that operational burden gets repeated for every client you onboard.

4. Maintenance: the architecture decides how much you inherit

Every live client site can generate recurring work.

Core updates.

Security patching.

Backups.

Extension compatibility.

Troubleshooting.

Support requests.

Whether that work becomes profitable depends partly on your agency model. If maintenance is included without being priced properly, it becomes overhead. If maintenance is intentionally sold as a service, it can become revenue.

The underlying platform architecture matters here.

With an assembled stack, a core platform can be extended with third-party tools and plugins.

That can provide enormous flexibility.

But every additional dependency can also introduce its own updates, compatibility requirements, pricing, and maintenance.

With a more native platform, more functionality is maintained within one system.

That can mean fewer separate systems to assemble and maintain, but potentially less flexibility when you need functionality outside the platform.

Neither approach is automatically correct.

The important thing is knowing which operating model you are choosing.

5. Price the tenth client site, not the first

This is one of the most useful ways to think about agency software:

Price the tenth client site, not the first.

Entry pricing is usually evaluated by someone running one website.

A growing agency will not stay there.

Model the platform at the size you expect your client roster to become, not only the size it is today.

Pricing models can differ structurally.

Some platforms charge per site.

Some charge per account.

Some charge based on the number of live sites.

Others combine site plans, workspaces, seats, and additional services.

So build your model with every line that scales:

Platform charges
Per-site costs
Team seats
Feature tiers
Hosting
Paid extensions or plugins
Renewal pricing
Maintenance time

That final line is easy to overlook.

Your team's time is part of the platform cost.

A platform with a lower subscription price can still be more expensive operationally if every client site creates additional recurring work.

The number you actually want is:

What is the fully loaded cost of one more live client site?

Then model that across the roster you are planning to build.

6. Native platform or assembled stack?

Underneath many of these decisions is an architectural trade-off.

An assembled stack

An assembled stack starts with a core and adds additional parts.

The ceiling can be extremely high.

If a client needs unusual functionality, there may already be a tool or plugin for it. If there isn't, a development team may be able to build it.

The trade-off is that your agency owns more of the integration and maintenance.

A native platform

A native platform ships more functionality as part of one system.

There are fewer separate pieces to assemble and potentially fewer independent systems to maintain.

The trade-off is that when you need something outside the platform's capabilities, your options may be narrower.

The right choice depends on how your agency works.

Ask yourself:

Do our clients regularly require highly specialized functionality?
Are most projects variations of a repeatable website model?
Is ongoing maintenance a service we intentionally sell?
Or is maintenance overhead we are trying to reduce?

That last question can completely change which platform makes sense.

7. Where SGEN fits

SGEN is an example of the native-platform side of this decision.

It is a website builder and CMS positioned for growing web design agencies that prefer a more native, out-of-the-box setup.

Some of the capabilities relevant to agency operations include:

Site Manager for managing multiple client sites from one dashboard
Stage and Live environments for working between staging and production
Clone-forward workflows for using a proven build as the starting point for another site
Sandbox for building staging sites before taking them live
Built-in user roles and login-as-client for client access and support workflows
Foundation Pack covering infrastructure including hosting, SSL, CDN, WAF, and security patching
23 native modules available across the platform rather than unlocked through feature-based plan tiers

SGEN prices plans based on the number of live sites rather than unlocking different product capabilities at different tiers.

That is one pricing model among several, not automatically the correct one for every agency.

Run it against your own roster.

There are trade-offs too.

SGEN is a newer platform without the long independent review history of established website builders. Client billing and invoicing are not currently listed as native capabilities in its published documentation, and migrating a WordPress website involves rebuilding rather than a one-click design import.

That matters.

Choosing an agency platform should be about fit, not pretending every platform solves every problem.

For agencies that want to reduce the number of separate systems behind each client site, SGEN represents one approach worth evaluating.

For agencies whose work depends heavily on a large third-party ecosystem or whose business model intentionally revolves around technical maintenance, another architecture may make more sense.

8. The agency website builder checklist

Before committing your client roster to a platform, answer these ten questions.

1. How will we manage 10+ client sites?

One dashboard or ten separate workflows?

2. What does another live client site actually cost?

Include the platform, seats, hosting, extensions, and your team's time.

3. What can we reuse from one project to the next?

Structures, components, staging environments, templates, or only memory?

4. What access can we safely give clients?

And what can they accidentally change?

5. What maintenance does the platform create?

Per site, per month, and who absorbs it?

6. Which capabilities require additional tools or plugins?

Count them. Then price and maintain them.

7. How does client handoff work?

Think about the account, billing, content, permissions, and ongoing support.

8. What happens when the team grows?

Consider per-seat costs and permission controls.

9. What happens if the client wants to leave?

What can be exported? What needs rebuilding? What gets left behind?

10. Does this platform fit how our agency actually makes money?

Design margin?

Development?

Recurring services?

Maintenance retainers?

The answer matters more than any feature comparison table.

The takeaway

The right website builder for an agency is not necessarily the one that makes the first site easiest.

What matters is whether its operating model still makes sense at ten sites, twenty sites, with a growing team, clients who need access, and a maintenance load that someone has to carry.

Evaluate the platform as part of your agency operation, not just as a design tool.

SGEN published a deeper comparison of seven agency website builders across pricing, ease of use, features, and project management.

👉 Read the full agency website builder comparison on SGEN

You can also explore SGEN for agencies.

What did your agency underestimate when choosing its website platform?

For many teams, maintenance only becomes visible once the client roster starts growing.

The Hidden Cost of a Plugin-Heavy Website Stack

Clark Pesa — Fri, 28 Aug 2026 03:15:08 +0000

A website rarely starts with 20 plugins.

It usually starts with a simple requirement.

You need a contact form, so you install a form plugin.

You need better control over SEO, so you add another.

Then come redirects, analytics, backups, security, caching, popups, and a page builder.

Each tool solves a real problem. But over time, something else happens: the website becomes a stack of independently maintained software.

And that stack becomes part of what you have to manage.

The problem isn't simply the number of plugins

There isn't a magic number where a website suddenly has "too many" plugins.

A site with a larger collection of well-maintained plugins can work perfectly well, while a much smaller stack can cause problems if one component is poorly maintained or conflicts with another.

The more useful question is:

Do you know what every part of your stack is doing and why it's still there?

Plugin stacks tend to accumulate over time.

A developer installs one tool. An agency takes over and adds its preferred tools. A temporary marketing campaign requires another plugin. Months later, the campaign is gone but the plugin remains.

Eventually, nobody is completely sure which tools are essential, which overlap, and which can safely be removed.

Every dependency has an operational cost

The price of a plugin is only one part of its cost.

Each third-party dependency can introduce another:

Release cycle to follow
Update to test
Vendor to depend on
Potential compatibility issue
Configuration to maintain
Subscription or license to renew

For one website, that overhead might be manageable.

For an agency maintaining dozens of client sites, however, the same maintenance work gets repeated across an entire portfolio.

That's where architecture starts becoming a business decision rather than just a technical one.

Start by auditing the stack

Before replacing anything, understand what you already have.

A simple plugin audit can start with four questions:

What does this plugin actually do?
Does another tool already provide the same functionality?
Is the plugin still actively maintained and necessary?
Could the platform handle this capability natively instead?

Grouping plugins by capability rather than by name can make overlaps easier to spot.

You may discover that multiple tools are handling parts of the same job.

Native functionality changes the equation

There is another approach to website architecture: moving common functionality into the platform itself.

Instead of installing separate products for common requirements, a platform can provide capabilities such as forms, SEO controls, redirects, analytics, backups, security, and content management natively.

That doesn't mean specialized tools are obsolete.

There are plenty of situations where a dedicated product is the better choice. Complex ecommerce requirements, advanced conditional forms, or highly specialized business workflows may need functionality that an integrated platform doesn't provide.

The advantage of native functionality is not that it can replace every specialized tool.

It's that you don't have to assemble the basics from scratch.

This is one of the ideas behind SGEN

At SGEN, we've taken the integrated approach.

SGEN is a website builder and CMS where core website capabilities are built into the platform as native modules rather than assembled through a traditional plugin stack.

The goal isn't to argue that plugins are inherently bad. Plugins have made platforms like WordPress incredibly flexible.

The question we're interested in is different:

How much third-party dependency should a modern website actually require?

For teams managing multiple websites, reducing unnecessary dependencies can mean fewer separate systems to maintain and a more predictable workflow.

We've also put together a deeper guide on auditing plugin dependency, including how to identify overlapping functionality and decide what should stay, be replaced, or be handled natively.

Read the full WordPress plugin dependency audit on SGEN

The takeaway

A plugin-heavy stack isn't automatically a bad stack.

The real warning sign is a stack that has grown without anyone periodically asking why each dependency is still there.

Whether you stay with WordPress, move to an integrated platform, or build your own architecture, the same principle applies:

Every dependency should earn its place.

When was the last time you audited everything your website depends on?

Why We’re Building SGEN Differently: A CMS Without the Plugin Stack

Clark Pesa — Tue, 25 Aug 2026 23:52:51 +0000

Hi DEV Community 👋

We’re SGEN, and this is our first post here.

SGEN is a flat-rate CMS built around a simple idea: website teams should spend less time managing the stack and more time building and growing their sites.

The problem we wanted to address

Modern websites often depend on a growing collection of separate tools.

A CMS handles content. Plugins add functionality. Another service handles forms. Another handles analytics. Hosting lives somewhere else. Security needs its own setup. SEO introduces another set of tools.

Each addition can solve a problem, but it can also create another dependency to maintain.

For agencies managing multiple websites, that complexity can multiply quickly.

A different approach

SGEN brings essential website capabilities into the platform through 23 native modules.

Instead of building around a large collection of third-party plugins, the goal is to provide the tools teams regularly need within one CMS.

SGEN also includes hosting, security, SEO, and server-side rendering as part of the platform.

And our pricing follows the same philosophy:

Pay for sites, not features.

The 23 native modules are included across our plans. As your needs grow, you're primarily scaling the number of live sites rather than unlocking individual features one tier at a time.

Why we're joining DEV

We don't want this organization to simply become another place to post product announcements.

We'll be sharing what we're learning about:

CMS architecture
Website performance
SEO and technical SEO
Managing multi-site workflows
Native modules vs. plugin-heavy stacks
Building and maintaining websites at scale

We'll also share some of the decisions, tradeoffs, and problems we're encountering as SGEN continues to evolve.

We're looking forward to learning from the DEV community as well.

What creates the most friction in the CMS or website stack you use today?

We'd love to hear about it.

Native Modules vs. Plugins: What We’re Building at SGEN

Clark Pesa — Tue, 25 Aug 2026 05:42:49 +0000

Why SGEN Is Taking a Native-Modules Approach to CMS

Hi DEV Community!

I’m Clark, a Growth Marketer at SGEN, and I wanted to share something I’ve been learning while working with the platform: why SGEN is built around native functionality instead of relying heavily on plugins.

What is SGEN?

SGEN is a modern CMS and website builder designed to bring the tools needed to build, manage, host, and grow websites into one platform.

Instead of starting with a core CMS and adding multiple third-party plugins for common website functionality, SGEN includes 23 native modules across 7 categories.

That means features are designed as part of the platform rather than being added later through a collection of separate plugins.

Why take this approach?

One thing I've noticed while learning more about CMS platforms is how quickly a plugin stack can grow.

You might need separate solutions for SEO, forms, analytics, redirects, security, performance, and other functionality.

That flexibility can be useful, especially when a website has very specific requirements.

But it can also mean more dependencies to manage.

SGEN takes a different approach: build commonly needed functionality directly into the CMS.

The idea is to create a more unified environment where the individual pieces are designed to work together.

It's more than just the modules

Another thing that makes SGEN interesting to me is that the CMS isn't treated as the only part of the website stack.

Hosting, security, SEO capabilities, and server-side rendering are part of the platform as well.

From my perspective on the growth side, that matters.

SEO and discoverability aren't only about keywords and content. How a website is built, rendered, structured, and maintained can influence what marketers are able to do after launch.

Working at SGEN has made me pay much more attention to that relationship between development and growth.

Native functionality vs. flexibility

Of course, there is a trade-off.

A large plugin ecosystem gives developers enormous flexibility.

A native-module approach gives up some of that open-ended choice in exchange for a more controlled and integrated environment.

SGEN is betting that for many websites and agencies, reducing the number of separate tools that need to be installed, maintained, and paid for can make website management simpler.

Whether that approach makes sense depends on the project.

And that's actually what I'd like to learn more about from developers here.

When choosing a CMS, do you prefer having more functionality built into the platform, or having a lightweight core and choosing your own plugins?

I'd love to hear how you evaluate that trade-off.

Hi DEV Community! I’m Clark 👋

Clark Pesa — Tue, 25 Aug 2026 05:10:19 +0000

Hi everyone!

I’m Clark, a Growth Marketer at SGEN, and this is my first post here on DEV Community.

My background is more on the marketing and growth side, but my current work has brought me much closer to the technical side of the web — SEO, CMS platforms, website performance, search visibility, structured data, and how developers build websites that are actually discoverable.

One thing I’ve been learning is that growth and development are much more connected than they sometimes seem.

A technically great website still needs to be discovered. At the same time, good marketing can only go so far if the technical foundation of a website creates problems for performance, SEO, or user experience.

That intersection is what I’m hoping to explore here.

I plan to share things I learn from working on SEO and growth for a CMS platform, experiments that work (and sometimes don’t), and observations about how technical decisions affect discoverability.

I’m also here to learn from developers who understand this side of the web much better than I do.

If you work in web development, SEO, CMS, or growth, I’d love to connect.

Looking forward to being part of the DEV Community!