Over time, the projects changed. Websites became ecommerce platforms. Ecommerce platforms became connected business systems. A project that once involved a web server and a database might now involve a CRM, payment processor, fulfillment provider, subscription platform, customer data, third-party APIs, and years of history that can’t simply be replaced.
About
The web got more complicated. So did the work.
Phillips Web Development Company started where the name suggests: building software for the web.
TL;DR
Phillips WDC evolved with the work.
Today, we focus on the systems underneath modern businesses — the integrations, architecture, data, automation, and custom software that make everything work together.
Built by an engineer who still likes building things.
Kevin J. Phillips
Founder & Principal Software Architect
I’ve spent more than 25 years building software for the web.
Phillips WDC didn’t start with a grand business plan or a carefully developed philosophy about software architecture. I started it because I loved writing code, building things, and solving problems.
A lot of the philosophy came later.
Over the years, the way I approach the work has changed. I’ve learned to appreciate simpler solutions, to understand the cost of complexity, and to recognize that knowing what not to build can be just as important as knowing how to build it.
I’ve also learned that sometimes it’s worth bolting the wings onto the airplane before you try to take off.
You learn a lot doing this for 25 years.
Today, I still write code, but much of my work happens before and around it: understanding how systems fit together, deciding where data should live, designing integrations, working through migrations, finding failure points, and determining what actually needs to be built.
Experience hasn’t made me less interested in building things.
It’s made me much more deliberate about what we build and why.
How we think about the work
Four things that shape every engagement.
01
Understand before building.
Technology comes after the problem. Before changing a system, we want to understand what it does, who depends on it, where the data lives, and what happens when something goes wrong.
02
Own the difficult parts.
Integrations, migrations, edge cases, failure conditions, and the awkward spaces between platforms aren’t someone else’s problem. They’re usually where the real engineering begins.
03
Use the right tool.
Shopify, WordPress, custom software, serverless infrastructure, or something else entirely — we don’t need every problem to have the same answer.
04
Build for the people who inherit it.
Software eventually belongs to someone other than the person who wrote it. That means readable code, sensible architecture, documentation, version control, and systems that don’t require the original developer standing nearby to explain how everything works.
Sometimes the best solution is something new.
Sometimes it’s fixing what you already have.
And sometimes the best engineering decision is not building anything at all.
Start here
We like difficult problems.
If your systems have outgrown the way they were originally built, if platforms that should work together don’t, or if you’ve reached the point where another plugin or SaaS subscription isn’t going to solve the problem, that’s usually where the conversation gets interesting.
We don’t expect you to know what technology you need.
Tell us what you’re trying to solve. We’ll start there.