See all Insights

We Don’t Build Websites Anymore

Don’t panic. I know that sounds crazy.

But to be honest, the word website has for quite some time been inadequate to describe what we are in the business of creating. Sure, you can still go out and buy a website, but you shouldn’t. Websites alone don’t do very much; what you need is far more complex than pages and forms.

Quibbling over what a website is or should be isn’t really the point. We need to reframe our entire concept of web development, and that is a two-step process. First, in terms of widening the scope of what marketing and sales-focused websites do today — which we believe is best expressed by locating them within a broader lead development ecosystem — and second, in terms of understanding what web development as a discipline is becoming — which requires drawing a distinction between platforms and programs. Sophisticated web development is no longer about creating discrete applications, but doing what we call information logistics.

Don’t worry, we’re going to explain all of this.

I don’t mean the royal “we,” by the way. Mark and I have been developing/discovering these ideas together over the past year or so, and we’ve decided to share them with you collaboratively in this article. I’m going to first turn it over to Mark to describe the lead development ecosystem as it exists today, and then I will return to describe the larger transition we are making from web development to information logistics.

Hold on to your hats…



Mark O’Brien, CEO

The Lead Development Ecosystem

OK, so I tested this whole “we don’t build websites” idea on a long-time agency partner the other day, and it took one too many reassurances that “yeah, we actually do” for me to decide not to play too close to that fire.

So, now that we’ve got you reading, yes, we still build websites — but we don’t build standalone sites. We now focus solely on building Lead Development Ecosystems, and while the conversion-focused website represents one third of the Ecosystem, those other two thirds — the CRM and Marketing Automation tool — are critically important.

We’ve been in business for 18 years now as web developers, and the entire time we’ve had only one goal in mind, but until now that goal was at least partially unreachable. It turns out that we really like being in business. We like our employees; we like our clients. The work we do is important, it’s fun, and it’s quite rewarding. As I was thinking when I got up at 4:30 Tuesday morning for a 19 hour same-day trip to Albuquerque — there are a lot worse ways to earn a living.

Chris and I, as a unit, are surprisingly conservative, and I live in constant fear that if we can’t hit our goal of proving that the work we’ve done for our clients has generated enough revenue for them to make their investment in their site seem paltry by comparison, there’s something wrong. I know most agencies feel the same way. The problem is the whole “proof” thing. How do we know? How do our clients know? How do we know if they know? Up until now, it’s been a little foggy. Now, it’s clear as day.

The Lead Development Ecosystem, in case you haven’t read or watched anything we’ve been doing for the past 6 months, is the synthesis of three tools — the conversion focused website, CRM, and marketing automation system. It runs on two ingredients — the right quantity and quality of contacts and content, and it’s entirely based upon the only thing any good marketing effort can be based on — a unique selling proposition.

We’ve identified this ecosystem, defined it, and we’ve become highly experienced and careful practitioners of it. Now that we’ve seen the power and sheer accountability the Ecosystem represents, going back to just building a site seems ridiculous. We can’t do it; it’d be like putting the training wheels back on the bike — why would you?

A website is something your client’s IT team claims domain over and promises to spit out in three months, something your nephew can build for you overnight, something Network Solutions can automatically build in the seconds it takes your credit card to process the extra $5.99 while you’re registering your domain name. It’s a brochure, a billboard, a yellow page ad. It won’t ask for much from you and it’ll give as much in return.

The Lead Development Ecosystem isn’t a way for us to justify our well-heeled ways or our existence as a firm that specializes in “web development.” It’s a solution that answers the question we’ve been asking ourselves for 18 years: How can we create a system that has an undeniably and measurably positive impact on our clients’ business?


Why Does This Matter To Agencies?

It’s no secret that independent agencies have been Newfangled’s lifeblood for our entire existence. We earn about 30% of our business from agencies that hire us to do their own sites and the rest from agencies that partner with us to build sites for their clients. If our partners aren’t doing well, we aren’t doing well.

The Lead Development Ecosystem is critical to independent agencies for three key reasons.

1. It Imposes Rigor

The foundation of the Ecosystem is having a unique selling proposition. It forces you, as an agency, to commit to a specialization that allows you to meaningfully stand out from the competition. If you want to take advantage of the Ecosystem, you can no longer rely on being all marketing things to all people in your local market. You need to choose a specialty and focus on at least a national market.

Once you do commit to a specialized position in the marketplace, you can then buy lists of people who actually need your services and write content that is meaningful to them. If you aren’t a specialist, you can’t buy contacts, and you won’t be able to write compelling content because you won’t have a specified persona for whom you’re writing. If you try to adopt the Ecosystem for your firm by putting a conversion-focused website, CRM, and marketing automation tool in place but skip the foundational elements of positioning, contacts, and content, you’ll have a very expensive and mostly useless set of tools on your hands.

The Lead Development Ecosystem makes you a better agency by forcing you to commit to being a specialized expert, and then commit to writing content on a regular basis about that expertise to specific personas you have in mind — prospects who may not know you exist but need your expertise. The Ecosystem makes you much smarter, and brings a highly potent focus to your marketing which today is sorely lacking for the majority of independent agencies in North America.

2. It’s the Single Best Way to Create and Nurture Leads

We all know that even the best independent agencies in North America are typically lousy at marketing themselves. Even though they know all the right stuff, they just can’t seem to prioritize their own marketing over client work — at least not until the client work dries up, and then it’s too late to market. Remember, marketing is about the kinds of clients you want to be working with a year from now, not the clients you have or need today. Marketing is a long-term and constant proposition, not an every-once-in-a-while-when-you’re-desperate tactic.

It’s ironic that we’ve been able to make a great living helping the best marketers in the world market themselves. Despite this paradox, it’s an incredibly important job we have, and we love it.

The Lead Development Ecosystem is the only marketing platform that can independently attract, inform, engage, and nurture qualified-but-unaware prospects. It’s far more measurable — and therefore, refineable — than any other marketing option independent agencies realistically have. Agencies absolutely must employ this system for their long-term wellbeing.

I want to be honest with you by saying that I’m not writing this to get agencies to hire us to create the Ecosystem for them, per se. I’m writing this because I truly believe it is the most viable marketing option agencies (really, most businesses) have at their disposal today, and I very selfishly want to make sure that all of our current and future agency partners are incredibly successful. To borrow a phrase from my Pétanque team: “Without you, there is no us.” 🙂

3. You Can’t Do it for Your Clients if You Can’t Do it for Yourself

Because we’ve been working so closely with agencies for so long, we’re very aware that they are increasingly judged by both prospects and clients on their digital marketing capabilities. The Lead Development Ecosystem isn’t a Newfangled pipe dream. It’s the product of many years of critical observation; it is the playbook for the current best practices for lead development (digital or otherwise); it is the state of the art.

As the word Ecosystem implies, it is a complex interweaving of many different technologies, strategies, and perspectives. Compared to this, the learning curve for figuring out how to deal with blogging, social media, and mobile is barely a curve at all. The mastery and assimilation of those things into your portfolio of deliverables is elementary compared to truly understanding and adopting this system. This is not something that can be offered and delivered to your clients by faking it until you make it, nor is it something you can have a few people dabble in before you declare yourselves experts in it. It is something you’re only going to truly understand and deliver if you wholeheartedly adopt it for yourselves and continue to live by it.

The nice thing about this is that if you buy point #2 above, you’re going to want to do this anyway. The terrifying thing about this is that it’s more complex and difficult than any other digital marketing challenge your firm has ever faced. Indeed, it is the synthesis of all of them put together in a specific way that allows them to equal far more than the sum of their parts, and, of course, makes them worth far more as well.

This is the present. It is how marketing is being done at this moment by many of your future clients.

Now, to the future. Take it away, CB!



Chris Butler, COO

Information Logistics is the Future of Web Development

You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.
— Joe Armstrong

The history of programming is a story of abstraction. Studying that history feels almost like reverse-engineering years and years of cryptography — peeling back layer after layer of coded language and symbols. At the surface are recognizable words like “if” and “print”; deep down beneath, dense patterns of ones and zeros.

For programmers, the abstraction principle is both the key to unlocking that coded history and a core value: never duplicate information if you don’t have to. Over time, this principle has guided the evolution of programming from countless rows of binary expressions into much more complicated routines that are, ironically, a breeze to express — from low complexity at high volume to high complexity at low volume. In other words, we went from having to rewrite the rules of language, speech, and customs every time we wanted to say “hello” to just being able to say “hello.” And while abstraction may take today’s programmer farther and farther away from the “guts” of code, it saves an incalculable amount of time. Which is great if all you want to do is make a few boxes of text and images appear on a screen. Hello.

Imagining peeling back these layers of language gives us a decent picture of timing — of how the complexity of programming has accumulated over the years — but today’s development environments are really better illustrated with another image: nested dolls. None is truly self-sufficient. In fact, they are — quite literally — programs running within other programs. Languages spoken within languages spoken within languages. Inception!

Take PHP, for example. Originally created in the C programming language as a set of scripts used to maintain a personal homepage (the original meaning of the acronym PHP, by the way), it quickly expanded to a robust language of its own consisting of thousands of functions that programmers use to create websites just like this one. PHP has only been in wide use since 1997, and yet it is estimated to have been installed on millions of servers and hundreds of millions of websites since then. PHP is a language, but it’s also a program you install. PHP can’t run independent of an operating system like Linux, and without C, there is no Linux. Which means that how you express something in PHP is dependent upon how things are expressed in C. Like I said, nested dolls. And really, it’s far more complicated than I can express here without losing you to Buzzfeed or whatever. So, moving on.

All of this makes pretty good sense when you think of websites as one-way communication tools. You setup a server, install an operating system on it, install PHP in that operating system, then get busy writing functions in PHP. Those functions serve up the content of the website to those who access it. But, we all know that websites today do far more than just run their own programs containing and displaying information. Situated at the center of the lead development ecosystem that Mark describes, they have become platforms responsible for the complex exchange and processing of information. They share it with outside databases and they request and consume it from outside databases. Which means that they have to play by the rules those databases set. It’s like diplomacy: different customs, different languages, different procedures. One big, complicated but fascinating ecosystem.

This is why we have APIs. Application programming interfaces (API) make it possible to share content between different platforms in a variety of different ways. In fact, most of the functionality that has become pretty standard for today’s website is reliant upon APIs from various external platforms that describe their preferred formats for request and response messages, specific terminology for objects within their databases, and any other rules or restrictions of use of content. As you might imagine, the quality of an API can be measured by the depth of its user’s manual. Whether it’s as basic as embedding content — YouTube videos, Twitter streams, SlideShare presentations, and the like — a bit more sophisticated, like pushing and pulling notifications or web-to-lead integrations with your CRM, or as ultra-complicated as inventory reconciliation can be, it’s all done using some kind of API.

Thank goodness for APIs.

The picture this should be painting for you is of a discipline in process — an evolution of web development from a solitary, creative act (though hear me, there is still an abundance of creativity at work) to a cooperative, logistical practice. It’s become less about building content databases from the ground up, and more about brokering the exchange of content from one system to another. Less writing, more translating.

But wait! You probably won’t be surprised to hear that while we spend at least half of our time and effort in a web development project figuring out how things will work, we spend what seems like the equivalent amount of time on how things look. Still! And while HTML and CSS have gotten far more sophisticated over time, I’m still going to win friends and influence people by being pedantic and saying that writing HTML and CSS isn’t really programming. It’s markup. Even Javascript, which is a bit further along the spectrum toward programming, is becoming so standardized that it’s pretty rare for developers today to spend much time writing it from scratch. Instead, we borrow from libraries. Most of the stuff that we imagine when we think of websites — all the whiz bang stuff that we think is what websites are really about, like responsive grids, transition animations, slideshows, expanding and contracting layers, div overlays, tabbed interfaces, fancy menus, sticky elements, even typography — is becoming pretty plug-and-play. Well, to be fair, plug, play, and debug. But the point is, you find it, copy, paste, and tweak. I certainly don’t mean to cheapen any of the skills therein, but to build a website today that consistently works within the ecosystem requires standardizing techniques and replicating them rather than reinventing them each time. But watch closely: commoditization is the price of standardization.

You see, the ecosystem is growing in platform complexity, but stabilizing in terms of display methodology. I’m going to go out on a limb and say that a radical shift in markup techniques is far less likely than the creation of a disruptive new platform that does something with existing information that has never been done before. Which means that the value of front-end web development is dropping, while the value of the unseen stuff — the information logistics working behind the scenes — is rapidly increasing. This is the future of web development. Information logistics — not front-end visualization — is where you need to focus and position your development capabilities, lest you be underbid by someone who can do it cheaper or rendered obsolete by some system that makes it all just work at the click of a button. When your expertise is in connecting platforms, the appearance of a new one is opportunity knocking, not slamming the door in your face.

Or, as every consultant ever has said, sell strategy not tactics. Build platforms, not programs.

I think a couple of practical examples would be helpful to demonstrate that what I’m talking about is already in motion, not a far-off possibility.

Salesforce used to be a fairly simple web app. Now it’s a platform. It’s the central database for sales and marketing for many, many companies. It pushes and pulls information from innumerable places; it provides critical reporting; it’s more customizable than most users will ever know, and for those that run into limits, it’s an open marketplace for developers who want to build new tools using its API. In the beginning, we built websites that pushed form data to Salesforce’s database. Simple web-to-lead. Today, we push and pull — user-generated data, like form submissions and session data, as well as system-generated information, like lead-scoring and automated program data — with such frequency that many of the connections are now built into our core CMS, rather than implemented on a project-to-project basis. We made this architectural decision for practical and strategic purposes. Practically, why repeatedly rewrite the code that makes logistics work between our clients and the ecosystem when we can do it once and centralize servicing that functionality long term? Strategically, we’re betting on the power of Salesforce to consolidate the majority of digital sales and marketing functions so well that there is no viable alternative. While we’re expecting plenty of new platforms to emerge and continue to make our expertise valuable, we’re confident about this particular platform’s long-term viability. Anyone doing web development in the digital marketing space today needs to know the Salesforce API backward and forward.

What Salesforce is doing for sales and marketing, Amazon is doing for e-commerce. Namely, major consolidation. If you’re committed to Paypal, Intuit, Shopify, or even Magento, know that each of them — even at their various levels of reach and complexity — will eventually be subsumed by Amazon, either by direct acquisition or by the inevitable customer attrition that will occur when they simply can’t offer a better deal than Amazon. They’ve got a mix of offerings, including installable storefront systems as well as payment processing. Few solutions do both really, really well. In fact, the more sophisticated the e-commerce store, the less satisfactory an out-of-the-box storefront architecture is going to be. Same thing with a processor. If you have a client that requires the sophistication of one of Paypal’s top-tier processing services, they’re probably going to need a custom architecture and inventory system and be willing to pay for it, rather than be shoe-horned into something amateur like an offsite Paypal storefront. Now, of course, there’s plenty of nuance in between. But the world of e-commerce is relatively fractured in this way and, therefore, offering a prime opportunity for the right platform to consolidate it. Even today, e-commerce represents just a single percentage point of overall, “offline” commerce. It’s got nowhere to go but up.

Amazon is likely to be that platform. For many, they already are. But there are plenty of indications that Amazon’s contribution to e-commerce is only just beginning. The closest thing Amazon has to a consolidated offering now is its Amazon Webstore platform, which is pretty compelling if you’re willing to cleave your online marketing and sales. You can build an entire web storefront with integrated processing and fulfillment using Amazon Webstore — cool! — but it’s not a CMS, so adopting it means limited content templates, limited integration with all those third parties I’ve been talking about, limited integration with your marketing-focused website and content, and a few other things that don’t exactly look solid from a user experience standpoint (e.g. separate store URLs, centralized checkout screens that are even less customizable). So no, it’s not a silver bullet. But, it’s also not going to be the last thing they build. It’s step one.

Step two and beyond involve expansions in all the disparate pieces of e-commerce: storefronts, payment processing, and fulfillment. In fact, a recent report from The Kernel argued that Amazon will move into logistics. I agree. Obviously. But The Kernel piece wasn’t talking about information logistics. It was talking about moving stuff from place to place — from factory to warehouse to your front door by way of good old-fashioned shipping containers and trucks. Look out UPS! Look out FedEx, USPS, and DHL! But what about information logistics? The Kernel piece mentions that Amazon has an API for its retail fulfillment system. How long until Amazon takes what it learns from its storefront system and its fulfillment API and joins them into a true turnkey e-commerce solution? Inventory management + storefront + payment processing + fulfillment? When they do, look out Paypal! Look out, Chase Paymentech, and Stripe!

Beyond that? Well, I for one don’t doubt Amazon’s ambitions. I could see them moving into product development, too. After all, offer me solid software that connects to my 3D printer, and I could consolidate my entire widget business — from development through fulfillment — with Amazon. Even today, Amazon is running a program they call Mechanical Turk, which is a system that allows you to outsource “menial” tasks to real, live people (mostly in third-world nations). Amazon is calling this “artificial artificial intelligence.” Aside from taking their cut of every transaction, the real value Amazon derives from this business is in R&D — in studying these simple tasks and building algorithms that can automate them. That process, of first outsourcing commoditized services, studying them at high volume, and then reproducing them with software, is reproduceable with just about any technical service that drops to commodity level — remember my earlier warnings about front-end development? When artificial intelligence is actually just a scaled human army, what it can do is accelerate the systems and processes that we’d otherwise wait to build until real artificial intelligence exists. But if there’s one thing we know from Amazon’s growth, nobody wants to wait for much of anything. And Amazon has the resources and reach to meet our need for speed. Look out front-end developers! Amazon is saying there is nothing that we can’t package and offer cheaper than you. Amazon could be the platform to end all platforms.


Why Any of This Matters

The lead development ecosystem exists today, exactly as Mark describes it. You need to know about that and plan accordingly. Quite clearly, it’s a manifestation of exactly the trend toward information logistics that I’ve been describing. But this trend is going to continue to strengthen until it results in the commoditization of what used to be the primary service for sale in web development, and that is a very real danger to many of today’s thriving businesses. It’s not going to change much overnight, of course. In fact, today we have more developers on staff than we ever have, and they are very, very busy. But if all they did was create templates and style sheets, they’d quickly grow bored and move on to challenges better suited to their talents. However, I can look at each project currently in production and, specifically, the time our programmers are spending on them and see that the majority of it is spent on the complex task of brokering the flow of information from a variety of systems through our platform.

The title of this piece isn’t hyperbole. We don’t build websites anymore. We build information logistics platforms for marketing and e-commerce. That’s our future, and, I believe, yours too.

Related Posts