Let me describe a typical dev agency to you. You might work at one, might own one, or maybe one day want to start one. The agency's got a super fancy "process" and a few very talented people on staff. Your go-to tech stack is some homegrown Wordpress casserole that one of your developers built, and it powers most of the new projects your agency builds. You've got some projects launched, mostly on WP. Your existing clients' requests are getting hard to keep up with because their stuff is breaking every other day. You've been playing around with new stacks, but you're kind of overwhelmed with all the moving pieces.

And you're always trying to win bigger and bigger projects because that's where the money is.

You recently got an RFP for a big project, and honestly, it scared the hell out of you. You really want to win the work, and the budget's healthy, but you have no clue how you're going to build it.

Design? No problem. But can your staff swing it on the dev side? Do you need to go look for another tech stack? Your homegrown WP boilerplate from 2016 is probably not gonna get forced into submission for this one. Maybe Laravel? What's gonna handle the auth? Stripe? Oh shit, the Laravel guy left because he was sick of working on WP sites, and all you have is WP Bakery "devs" (and they're all trying to leave too because they're sick of working with WP).

Damn, if you win this, ideally you can figure out how to build it within the budget and still make some money. And hopefully the client is happy. Oh yeah, that's the goal.

Here's a few typical projects that your digital agency might be tasked to build

1. A fancy microsite

The first project you'll probably come across is just a regular website. Your designers are going to go crazy, and the site's going to have a super polished frontend, but there's nothing special on the backend. Maybe Wordpress or Sanity for the CMS and then NextJS on the frontend? Can we sneak by with Webflow on this one?

2. An absolutely massive enterprise website

With this project, the CMS is going to get straight up dominated. Contentful + NextJS for this one, right? Hmm, there are some pretty specific features. Might need to roll our own backend for some of the custom stuff—let's just tack $30K on for that and figure it out when we get there.

3. A native app

This one will require auth and user-specific content. Damn, full custom backend needed for this one, huh? Budget's going to be big. Laravel + React Native, perhaps.

4. Custom ecommerce store

Now we've got to figure out a fully custom e-commerce build with product configurators. Maybe Shopify + Sanity can power the content and ecommerce sides if we do it right. Definitely going to be some custom backend work on this one, too, but maybe we can bolt on all that with a simple Node server or a few Lambda functions.

5. SaaS web app

Uh oh, this project requires subscriptions—so auth, user profiles, payment processing, gated content. No worries, Stripe does that. Let's build a completely custom Node backend and then just integrate Stripe. People do this all the time, right? Should we use some Node app framework like NestJS?

The dev side of digital agencies is hard

Let's take a second to revel in the complexity of modern web development.

There's a lot to learn and keep up with. Any given digital agency might be dealing with 10 different stacks and tools, all at one time. Unless you have the literal Hideo Kojima of web development on staff, you're gonna have a hard time building all this, as well as continuing to support these projects as they scale into the future.

From this list of 5 typical projects, your dev team might need to learn and build on 7-10 different stacks. And we all know that devs in the agency world come and go with the seasons. We also all know that tech comes and goes with the seasons as well. Ideally we can train up a few of the devs on the tech in this project so that if that one senior backend leaves, the team won't get hung out to dry.

If you're going to build a successful business in this line of work, you need to be successful in a lot of different areas. No. 1, you need to keep your clients happy. That way your work will speak for itself and your best leads will come from word-of-mouth. But to do that, you need to break your back working for them. Nothing good comes easy, and after all, your agency is better than the others because you're smarter, you work harder, and your team just oozes with talent.

But you need to price things right to win contracts, and then you need to deliver quality—and fast. If you do that, you get to keep the rest of the project's budget. If you end up paying devs to struggle, or have to train new devs on a stack that only one of your 10xers knows, you're going to be eating the bill on that one. The client doesn't care.

You need to keep things simple, spread knowledge through teammates, remove specific points of failure, and make it so that every time you build something, the next time it becomes easier.

This is why Payload exists. It comes from real-world agency experience and it let us build extremely complex things that blew our clients away, insanely quickly and under budget. When we started building on Payload, we were able to keep our budgets competitive and still absolutely thrill our clients with what we delivered. We were also very profitable and able to do work that we were proud of. No one else could keep up with us.

First up - simplify your stack

Before we had Payload, my agency built things on a ton of different frameworks. Laravel here, Wordpress there, Contentful there.

When one of those projects needed a new feature or a client called with an issue, our devs had to "ramp up" into remembering how it all worked before we could be productive. This was lost time for us, and it meant that we were moving slow. And the client didn't care—that was on us to worry about.

We rarely made profit from existing projects because we had to sink so much engineering time in.

Once we started building on Payload, things got so much more manageable. Every project was simple, organized, and declarative. Any developer could jump in and reason about the work that needed to be done, because they all became familiar with our simple backend tech stack—Payload. No more "ramping up"—just pull up the Payload config and do what you need to do.

That's one of the beautiful parts of building expertise in a specific framework—your team can concentrate on building shared knowledge and the work becomes easier.

Don't rely on unicorns

I've been in situations before where there was only one person that truly knew how a certain project worked, and that sucked—because they were the bottleneck. And they were probably always busy building some new project. If you concentrate framework-specific knowledge within a few specific devs, you will encounter a situation where your top devs are insanely busy, but the rest of your dev team is not.

I've consulted with bigger agencies where the junior devs sit around and wait for small projects to be tossed their way and are moreso being groomed for future productivity rather than actually pushing projects forward.

This problem permeates the entire engineering industry, but it doesn't have to be that way.

If you have a common stack, juniors will be able to be more productive, and the mid-level devs will be able to jump into more contexts. Seniors should be left to define your toolkit, and then the mid-level and junior-level devs should be the ones implementing.

If you get this right, everyone on your team can be equally busy, and when the unicorn leaves, you won't have to freak out for a few months until you bribe another unicorn to come into the stable.

Re-use everything you build

Possibly more powerful than stack simplification is re-usability. At an agency, you might have wildly different projects, but inevitably a ton of the features overlap with one another. Dynamic site-wide search, Stripe integration, auth, access control patterns, etc. If you're bouncing from framework to framework, you need to re-solve these common problems for each framework.

But if you're building with one framework that's extensible enough to solve for many of these different contexts, then you can solve these problems one time - and then re-use your code for every other applicable project. But you still charge the same. We did that more and more successfully toward the end of my agency's life (we shut it down to focus on Payload). But we were building massive projects super quickly and they got down to just re-using the super elegant solutions we had already built for other projects. This was thanks to how modular and composable the Payload config is.

We built a Stripe plugin, for example. We sunk some time into it initially to build it the right way. We didn't necessarily walk away with a ton of money lining our pockets from that first project. But a month later, we got another project that needed Stripe. And then we already had 90% of the code we needed.

And we still charged the same budget. The second time, we made out like bandits. That's where the money is in the agency world.

Figure it out one time, put it in your toolkit, and then re-use it as much as you can.

You can end up selling complex projects for a hefty budget that come with lots of features—redirects, forms, layout builders, third-party integrations, search, personalization, etc.

The design could become more costly to you than the dev if you have the right approach to re-usability. That's the dream.

Once my agency started realizing that dream, the best part was that the client would always be thrilled. We'd deliver exactly what we said we would, on time, and the result would always be better than they expected.

Everything I said above about the modern web being complex is absolutely the truth—but in the agency setting in specific, you're going to face all this complexity head-on. And then you're gonna face it again. You might struggle at first, and be a bit slower at adopting a new framework, but the second time you should be able to make it rain.

Avoid SaaS hell

Microservices are great for massive applications, but your little MVP for the company that's paying you $200K to try out a new idea doesn't warrant reinventing the infrastructure wheel.

They just need you to build an MVP. You can build and then scale, abstract, restructure, refactor, plenty of times into the future. All you need to worry about upfront is that the data layer is clean, portable, organized, and ownable.

Here's a good example of complexity for no reason: Many developers combine a headless CMS with a headless e-commerce vendor nowadays, and to me, that says that we really haven't figured out the internet yet. That's a lot of complexity just to build an ecommerce website. It better demand it.

Let's take a second and wonder—is this ever really going to be the best idea? Someone logs into Sanity, for example, to manage the product landing page, but then, oops—the product price, thumbnail, and description are stored in Shopify. Let's get a couple tabs going and then hope to Christ that the statically generated page on the frontend will get revalidated properly after we change all this stuff. Preview mode from Shopify? RIP. Maybe I should change the product thumbnail, description, and price in Shopify before I go to Sanity to see if I can get a true preview of what the new updates will look like.

I wonder if there are Ph.Ds in this type of thing. Might be necessary at some point if we keep going like this. But I don't think this is ever going to be the long-term goal here, especially if the project isn't doing a hundred million in revenue per year.

Just build it simply. Build it efficiently. It's probably going to lead to a better UX for product managers anyway.

Conclusion

Clearly I've gotten pretty excited here so I better pump the brakes. I guess I miss the agency world a bit. Didn't expect that, but it turns out that building products has its own set of stresses and workload involved.

I'm going to do a few more of these posts because I have a lot more to say on the topic. Maybe I'll discuss how to absolutely thrill your clients to drive increased word-of-mouth leads.

Then maybe I'll talk about how to keep talented engineers in the agency world. (Spoiler: they're probably churning because they hate the tools your sales team forces them to use. Cough, WP Bakery. Elementor. Shopify. WP in general. Magento. Bigcommerce. Drupal).

Follow me on Twitter if you're interested in more from my manic mind.

Like what we're doing? Give us a star on GitHub

We're trying to change the CMS status quo by delivering editors with a great experience, but first and foremost, giving developers a CMS that they don't absolutely despise working with. And these two things together really help optimize agencies in specific.

Try Payload in one line

Getting started with Payload is easy—and free forever. Just fire up a new terminal window and run the following command:

1npx create-payload-app