Hi there! I’m D’nelle. I own Berry Interesting Productions, a web development agency, and the mastermind behind No Kill Websites. No Kill Websites is a “no kill shelter” for abused, abandoned, or lost website owners who are looking for help making smart, long-term decisions about their sites. I’m originally from (and still very much tied to) Nashville, TN, but my home is now Denver, CO, and boy am I happy to live within driving distance of your city.
Inspiration for No Kill Websites - Berry Interesting *plus* rescue dogs. Cece is a beagle mix mutt - she was adopted from a no-kill shelter in Nashville. She was part of an unexpected/unwanted litter of 9 puppies. She came to us at 11 weeks old, and we did a terrible job of raising her. She has turned out to be a good dog despite our ineptitude. Annie is a pitbull mix - she came to us accidentally. We fully intended to foster her through healing from her spay surgery, but Cece fell in love with her and we ended up with another in-spite-of-ourselves good dog. Seriously - she came fully house-broken, has excellent recall, and makes Cece behave better.
Who is this talk for? It’s aimed at WordPress website owners who outsource - or are ready to outsource - some or all site development & support, but don’t want to be developers themselves.
The vast majority of us are experts at something else - writing, photography, making hippie-dippie soap - but we need WordPress to help support that expertise, and, as we grow, we will likely need a developer to help our site grow, too.
Before we dive into talking about how to have a healthy relationship with that developer, I want to acknowledge that there are plenty of things that you don’t need a developer for. I constantly shame Cece and Annie for not getting jobs and lazing around all day like princesses. Most of us don’t really *need* a cat or dog around... But boy oh boy do they make our lives better! My dogs lower my blood pressure, make me smile, keep me safe, and generally enhance my days. Just like most of us can get through life without an animal companion, so too can lots of us get through without a developer. But I’d argue - do you really want to? Cultivating a healthy relationship with a developer, even if you only engage with them once a year or so, can pay off big time in terms of the health and wellness of your site and your business. So, assuming that we want or need a developer… onward!
I’m going to confess something to y’all. I do not want to be a developer. You wouldn’t think that based on how the last decade of my life has gone, but I swear I don’t.The first WordPress website I built for a client - back in 2009 - was an eCommerce store for handmade soap. Linda had an existing eCommerce site with 42 products, but she couldn’t get her developer to call her back - and, when she did, she was billed an hour minimum for doing things like changing out the phone number in the footer of her site. She wanted more, but Linda is an expert at soap making (seriously. Her soap is amazing. Her brand is Alchemy of Sol, and I swear by it).
As a born people pleaser with more knowledge about websites than Linda, I jumped at the chance to help. I offered her a flat rate of $300 for the site build and another $500 for the eCommerce store. With no development knowledge at all, I use WordPress to build a site, with the Shopp plugin running the store portion and FirstData as the payment processor. Linda was so patient with me. I was upfront about the fact I was learning, and she gave me a looooooong leash. She was tolerant when I was ignorant and helpful when I asked for feedback. But she wasn’t a pushover, either. Part of why the build took so long is that she was committed to some store customizations. When she wanted something, she stood her ground, and gave me the time I needed to figure out how to give her what she wanted.Once we got that site built, it was incredibly easy to maintain! She continued to spend about $50/month with me for 5 years or more when she ran into something she didn’t want to bother with. But she was able to add products herself, add pages, and even change out the phone number in the footer of her site when she had the time & energy.. She relied on me for very little, but when she needed me, she reached out. We went on to have a long, positive relationship... until her son took responsibility for online marketing and I lost them to the siren song of SquareSpace… but that’s a different story.
Linda’s was not the last site that I built. In fact, I *built* two in the last four weeks. But what I learned from Linda, and the clients that came after her - many who are still with me today - is that I am NOT a **developer**. Like I mentioned on that last slide, Linda paid $300 for her site and then $500 for the store. It took me 12 weeks to build it, working 15-20 hours/week on the project. For those who aren’t interested in doing that math, that works out to a little less than $4/hour. I was making $8.70/hour at Starbucks at the time, and they offered health insurance. I have to attribute my persistence to a very strong stubborn streak, which - no matter what my mom says - I’m attributing to genetics. Anyway, it was not an easy 3 months. I sat at my desk at home, still smelling of coffee grounds, and took the hill of that learning curve like I was at war. I cried. Multiple times. I asked for help and was incredibly lucky to find kind, generous people to give it. And, at the end, it felt so good that I was crazy enough to take on another client (thankfully, not an eCommerce store).I really value that experience. It’s why I still push myself to learn new things. One time I built a plugin to display blog posts in the dashboard of client sites. Right now I’m learning how to build a custom post type. Both the plugin and the custom post type are pretty terrible, but now that I’ve been down that path, I have a deeper understanding - of what my limitations are, of what I’m asking someone else to do on my behalf, and of the effort it takes to do it well.Yes, it’s great being able to do things on my own, but what my development experience has taught me is empathy for both sides - client vs. builder/designer/developer. I spend a lot of my day “protecting” Cindy, the Berry Interesting Productions developer, from clients - ** and vice versa **The experience of being a developer is isolating. On any given day, a developer spends their time engaged in a very specific set of tasks. Some of those tasks are repetitive. Others require extensive research. Sometimes, you get a problem set in front of you and it’s something you’ve never seen. The simultaneous excitement and terror of that can be both motivating and exhausting.
Even working with a codebase that has gathered around it a HUGE and SUPPORTIVE community, when it comes down to it, hunting through code to squash a bug takes an incredible amount of focus. When my partner approaches me when I’m head-down in code, I am dismissive and distracted. I come off grumpy and irritated. That much time spent in my own brain means it’s easy for me to forget to eat and go to the bathroom. Let’s not even talk about remembering to take a walk or answer text messages.Trying to understand what work is like for your developer or designer, and understanding what it takes to do their job, can help you to see them as less intimidating and to cultivate an empathy for them that will make your relationship - and therefore your site - better in the short term AND in the long term.If you leave here with nothing else today, I want you all to leave with a commitment to empathy for those that you choose to bring on to help you make your website better than it is today.
An awareness of the differences in the tasks set before you in your day versus what your developer encounters can help keep you empathetic and sensitive to potential miscommunications or differences in opinion.I have so many clients come to me who know that they need a website… but that’s about all they know. Meanwhile, for a developer, they’re thinking websites all day, every day, and throwing out “I need a website. That’s all I’ve got.” is almost paralysing. You’ve got to be either very specific about what you need, or very specific about a problem that you need help solving.
When you’re going to a developer, it is in large part to make your life easier, to not have to think about the technical end of things so that you can focus on your area of expertise. But if it’s one thing a developer is not, it’s a mind reader. Even if that were the case, you’re still left with the problem of essentially speaking two different languages. Even if you’re communicating in English, a developer spends their days engaged in a very specific set of tasks that come with their own vocabulary - everything from acronyms like DNS, MX, and SCSS all the way to the code itself. Meanwhile, you have an experience of tech that is largely unknown to the developer and somewhat unique to you. A few examples: While trying to explain how Facebook Pages work, I made a client cry because they didn’t understand why Facebook requires a profile in order to create a page. I still have not successfully explained the difference between an email address and an email account to one of my DIY/coaching clients Last year, I had a client come to me with a website design done entirely in PowerPoint My dad can build a house from the ground up, but I’ve had to explain (and defend the use of) The Cloud, and why it’s okay to store your contacts on your gmail account, at least 5 times.
The point is, when a developer’s brain is focused on very specific and complex tasks, it’s not easy to step back into the wider world only to find that not only are you tasked with building a working eCommerce store, but you’re also meant to evaluate a client’s level of knowledge and then change your communication approach to meet the client where they’re at.This is why I have had a successful career as a project manager, because translating between client and developer can be a full time job!
Whether you’re looking to have a direct relationship with your designer or developer or you’re hiring an agency whose team includes a developer, your best approach is to, like a good dog, be friendly, attentive, empathetic, and receptive to direction.
When a dog comes into a new home, it takes a while to learn the new vocabulary. Is “get down” the same as “off”? Is “dinner” the same as “food”? Is “get in your crate” the same as “go to bed”?Luckily, since we are humans with opposable thumbs and access to things like google and email, we can get out ahead of that learning curve and try to stay there. As a client seeking development services, even though you’re outsourcing the real dirty work, I can’t recommend enough having a working knowledge of the vocabulary that developers use. Know the difference between a domain and an URL, a slug and a permalink, a page and a post, etc. It will help immensely at every phase of a project. Still, as a someone who is coming to a developer or agency looking for help, familiarity with vocabulary isn’t as important as familiarity with yourself, your project, and your goals. Before you even start looking for a development partner, ask yourself: What do you like? What do you want? What is your budget? What is your launch deadline? How responsive can you be? What is your website's expected life span?
These questions are just a start. If you’re interested in more about vocabulary or about project articulation, we’ve got a couple pretty handy downloads that you can find out on our website.
When Annie first ended up in our front yard, the first thing we did was take her to the vet. They asked the usual questions, ran the usual tests, and sent us on our way. No one let us know that unvetted dogs need a heartworm tests every 6 months instead of every 12, because it takes at least 6 months for a dog to test positive after it has been infected. Had I done independent research, I would have discovered that quite easily, but my prior knowledge of heartworms only included the “get tested every year” policy. When you’re looking for a development partner, there are some obvious and some not-so-obvious questions to ask as a way to assess both the health of that partner and your potential for compatibility.
References: Not only should you ask your developer directly for references, but you should do your own research as well. Contact the provided references Check their online portfolio - follow links out to the live sites wherever possible, and look around those sites. Check social media feeds - Not only will you get a sense of their vibe, but you can often find conversations between them and clients. Depending on what you find, you might ask the developer for a reference that might be less than flattering, or even ask the developer directly to share a story of a relationship gone bad. This depends on your comfort level, of course, but I’m not afraid to share the skeletons in my closet. They all reveal things about my approach and process that inform how I face future challenges. Check with the community - how involved is your developer in the WordPress community? Do they maintain any plugins on the WordPress repository? Do they participate in contributor days? Do they attend WordCamps or MeetUps? What kinds of relationships do they have with other developers, agencies, plugin/theme shops? While developers do tend to be introverts, the good ones are not islands. They care about having a healthy network of people they can turn to for help, advice, and mentorship Ask if not you, who? - This is my favorite question to ask, and it’s an extension of “checking with the community”. For instance, all the eCommerce sites that Berry Interesting Productions builds are developed in partnership with another agency, because that agency focuses exclusively on WooCommerce. For SquareSpace sites, since we’re not really interested in building them but we ARE interested in email marketing clients, we reach out to a specific freelancer who knows SquareSpace better than we do. On a regular basis, I refer potential clients to other developers and agencies, depending on their needs. If your potential developer can’t speak highly of another agency, that should be a big fat red flag. Hourly rate - if you’re intimidated or concerned by a developer’s stated hourly rate, this should give you pause. I started out billing $25/hour as a freelancer, and now I bill at $125. Both of those rates are, in my opinion, about 20% too low. When you ask a developer about their hourly rate, keep in mind that you generally get what you pay for in terms of efficiency and professionalism. Remember that soap website I built? My time was absolutely NOT worth $125/hour. I was slooooooow. I was also young, eager, learning while I worked, and getting a portfolio piece under my belt. That said - I was definitely worth more than $4/hour even then. Whether you’re working with a freelancer or an agency, there is overhead that goes along with development (hardware, software, plugins, continuing education, office furniture/space, internet, etc. etc. etc.). It makes me uncomfortable to pay anyone less than $20/hour; when I’m working with an experienced developer, anything less than $50 seems like an insult. Obviously, this could be a topic for a talk in and of itself. My point is that hourly rates signal more than just the value of someone’s time, and deserve consideration when evaluating a potential relationship If you can, do a small test project - when it comes to building a brand new website, this isn’t always possible, but when you have the luxury of giving a new development partner a test drive by engaging them for a small project, you can learn a lot about the way that they communicate and what kind of approach they take to project management. How long have they been around - and how long WILL they be around? Ideally, when you pick a development partner, you’re starting a relationship that will last many years. Just like you have to give animals time to orient themselves in a new house, and expect a few puddles on the floor while they do, so is there a learning curve when a new developer comes onto the scene. So many clients who come to me have sites that are utter rats nests in the back end, and having to explain “discovery” costs is a tough sell. While it’s never good to just “stay together for the kids” while hating each other, there is serious value in a long term relationship. You want to assess how serious your potential development partner is about staying in the business. Stability and familiarity can mean efficiency and ultimately lower costs. A good way to assess how serious a developer or agency is about the long haul is whether or not they provide a support package. Support packages are a great way for a developer and a client to formalize their relationship - not only does it provide for the wellbeing of a site, but it acknowledges that a client takes the developer seriously, and it provides stability to the developer (I’m way more likely to stick around if I know I can pay my rent every month!) Know your breed - designer, developer, super-user? We throw around terms like “developer” “designer” “webmaster” or even “content specialist” as though they have a standardised meaning, when they really do not. I’ve seen self-proclaimed developers who build entire sites without ever even opening up a php file, and I’ve seen “designers” who write code to modify plugins. So, how can you assess what kind of help you’re getting when job titles can be meaningless? Make sure you ask any potential development partner about their process. Ask about what plugins they prefer and avoid. Ask what framework they prefer to use, how they feel about theme builders, and whether or not they like to develop locally or on a web server. While you might not fully *understand* the answer, their level of confidence and transparency will signal to you how well they’ve thought out their own process and how well they understand their own limitations Another good way to test the waters is to ask what they recommend for keeping your site stable and secure over the long term. A security plugin is a good place to start, but the ongoing health of a site depends on more than just locking out IP addresses with failed logins. Asking a potential development partner about their security efforts, and about how they help clients keep sites healthy, will tell you how seriously they take your ongoing satisfaction.
The number one red flag for me is when someone tells me “that can’t be done with WordPress”. There are plenty of reasons something can not or should not be done in WordPress - the initial cost, the likely return on investment, or even something being outside of a developer’s skill set or preferred type of work (remember that WooCommerce agency I mentioned earlier? In the early days of their business, they built pretty much everything. Now, they’re successful enough that they say no to projects that they don’t want, and focus all their efforts onto eCommerce).
There are also reasons to not use WordPress, but, in general, there’s not much that *can’t* be done with WordPress, and that comment is a signal to me that the developer is hiding behind “it can’t be done” when the real answer is “I can’t do it with WordPress” or “I can’t do it within your budget with WordPress”. That comment should instead be something like “I wouldn’t recommend WordPress for this, and if you’re interested, I’d love to explain why”... or “That’s really out of my wheelhouse. I propose alternate solution x and/or I’d love to help you find someone with expertise in this matter”
Other red flags include: using a bajillion plugins - in addition to slowing down site performance (which can impact SEO as well as the user experience), this *can* be a sign of someone who is less a developer and more a super user (like me!). For instance, the plugin “Simple Staff List” (developed by a friend of mine in Nashville, Brett Schumaker) is a great way to get, you guessed it, simple staff list functionality on your site. I’ve used it before. But using that plugin instead of creating a custom post type would really only be advisable in a DIY, super-low-budget situation. Additionally, the more plugins you use, the more likely it is that one of those plugins will have code that conflicts with another plugin, or results in loading of duplicate scripts, which can cause functionality problems down the road. It’s harder for a site to be future-proof when you have code from many developers running simultaneously. Again, I’m not saying that this is bad, period, end of story. But the number of plugins in use can tell you something about a developer’s approach and their skill level no training provided - if a new site build does not include training (my rule of thumb is at least one hour for every $5,000 you spend), that’s no good. Even if all a site build consisted of was installing a pre-built theme and configuring a few plugins, a developer or agency should want to walk you through the customizations they made and show you how to use anything that affects your work on the site. No plan & no deadlines - While web projects, like construction projects, are notorious for going off schedule, it’s important for your development partner to set expectations for your project from the beginning, and keep you informed when those deadlines & expectations change. Going weeks without hearing from someone who you’ve put a deposit down with is infuriating. If a developer doesn’t have a plan in place for how to handle deadlines for you and for them, you’re bound to run into excessive delays You’re related to them - obviously, there are benefits to working with people that you already have personal relationships with, but in general it’s not a good idea. I have worked with multiple clients who came to me after their developer took their site down out of spite (in one case, the developer was sleeping with the client and agreed to build the site in exchange for him paying for her plane tickets to see him…. In another, the client’s ex-girlfriend owned his domain and his site and, post-breakup, refused to turn them over). It’s just better to not mix business and pleasure here.
So - s few specific tips for the care & feeding of your development partner. When you hire a developer or an agency, you’re not hiring an employee, you’re engaging a partner. Starting a relationship with a developer (or an agency where a developer is involved) really is similar to getting a cat. Even for people who hate cats, I promise you - there’s a perfect match out there. But that match - and the ongoing relationship - takes work. Provide the litter box & scratching post - remember - you teach your developer how to treat you. If you’ve got a project manager or account manager in the mix, that’s awesome! You’re still in a position where, as the client, you are in control of the terms of the relationship. If you know that you’ve only got 2-3 hours a week to have a meeting, write content, or provide feedback, establish that up front. I know that this is easier said than done - I am generally incapable of managing my own time - hello, 14 hours a day at my desk, goodbye hikes with Cece & Annie. But if you are proactive about communicating what you want and what you expect, you’ll get the same in return.
Structure & predictability - this tried and true dog-training advice works with your developer - maybe even better than with your pets. The first step to this is making sure you stay organized, personally. Often, an agency will have some infrastructure already in place - we love using TeamWork to corral tasks, deadlines, milestones and back-and-forth discussions! - but a solo developer might not. Decide up front - together if you can - where communication, file sharing, and project management information will live. Be open to new apps/tools that your developer suggests, or if you feel strongly about it (Basecamp vs. Asana, anyone?), request that they use your preferred method. That method should have a calendar attached to it in some way. Having a schedule and expectations in place gives everyone - you included - something to hold on to. Setting things up this way from the beginning will make everyone more comfortable and able to more easily focus on the work itself instead of the *way* you work.
Personal space - I want to caution you against - both during an active, ongoing project or afterwards when you’re in maintenance/support mode - overwhelming your developer with emails or calls or questions that aren’t related to the project. Ask for when it’s best to call or email, ask for an expectation for when those calls & emails will be returned. The toughest lesson I had to learn about this was having Annie & Cece get in their crates to sleep at night. I LOVE sleeping with them. I really do. Sometimes it’s more comforting than sleeping next to my partner (I have every right to steal a blanket from the girls - my partner, not so much). But I can’t get a real, true, good night’s sleep if they’re in the bed. They get up and move, or paw to be let under the blanket, or decide that 3am is the best time to bark at the bunny outside the window. It took a good month of whining before we got them to sleep through the night in their own beds, but it has made a TON of difference in my quality of sleep. I will admit that we do nap together occasionally, so I still meet my cuddle quota. You have to prioritize your own wellbeing - and know your own personal needs - to be at your best every day. Setting boundaries like this - and asking your developer to articulate their boundaries! - will make for a much happier team.
Respect, listening - Before we moved to Colorado, Cece, had been (aside from trips to the dog park) a 100% peeing inside kind of dog. It didn’t seem to faze her that Annie went outside several times a day while she used a puppy pad. When we moved, that abruptly changed. When we took Annie outside and left Cece inside, we were met with anger-peeing of the impressively consistent variety. It wouldn’t fail - while we were outside with Annie, Cece would pee on the rug by the front door. Never mind that she had the private space that she’s always craved outfitted with a clean pad. Nope - things were changing! We were angry for about a week before we figured out the pattern and started taking her outside alongside Annie. She doesn’t always actually go to the bathroom - it’s more like a sniffing-after-rabbit-trails break for her - but the anger peeing abruptly stopped. As much as we wish that they could both talk (because, lord knows, I desperately want to. I really want to know why Cece is compelled to eat goose poop, or why Annie *needs* to lick my chin), they have their own unique way of communicating. The secret has always been to acknowledge that they’re speaking in a different language and attempt to learn that language - even if that language is the language of rug-peeing. Sometimes you might need help getting matched up with the right developer or agency. We found Cece in an adoption facility in Nashville… and Annie just ran out in front of my car one fall day when I was feeling vulnerable and foolish. But I met my partner on Match.com… after enough awful dates that I was ready to adopt 3 cats and take up cross stitch (okay, confession - I do cross stitch already. But I was ready to be *public* about it, really lean into the spinster thing). Don’t be afraid to formalize your search for the perfect development partner. If you’re in a bad relationship now, do some journaling or list making about what’s bad about it… and what the ideal partnership would look like. Then, talk about it. Communicating to your support system what you’re looking for and what you need can get you to that “forever home” faster. As you’re looking, don’t forget that approaching a relationship with a developer or an agency as a *partnership*, whether you’re partners for a year or for 10 years, you will have found your “forever home,” because even when the partnership ends, that relationship will pay off big time. you’ll meet new partners who are better suited for who you grow to be, and you’ll always have a trusted ally who can help you meet those new partners.
Finding Your Forever Homepage
No Kill Websites
A Berry Interesting Production
Finding Your Forever Home Page
How to relax, listen,
and wag your tail
towards a happy
relationship with your
2006: Opened Berry Interesting Productions in Nashville, TN
2013: Adopted Cece as a puppy
2015: Adopted Annie from an abusive/neglectful situation
2017: Opened a second office in Denver,CO; started No Kill Websites
She’s a good dog!
Linda, the soapmaker
Sells her soap at farmers’
markets, in local shops, and online
Makes her product at home in her
garage in Smyrna, TN
Paid $300 for her first WordPress
website, and another $500 to add
It’s that darn cat again
What it’s like to be furry royalty
The developer experience:
● Begrudgingly affectionate
Fighting like cats & dogs
Has a lot of technical
Has big ideas
Is thinking about
the real world
Has a unique
experience of tech
Using the Dashboard
Basic site maintenance
Sometimes, you gotta walk yourself
What do you want?
What is your budget?
How much time do you have?
A Thorough Vetting
● Hourly Rate
● Test Projects
Assessing the health of a developer or agency
It’s me or the cat
Warning signs - when to run away
• “It can’t be done with WordPress”
• Plugin Overload
• No training provided
• No deadlines
• You’re likely to
them at a family reunion
Living happily ever after
● Provide a litter box & scratching post
● Strive for structure & predictability
● Establish personal space & boundaries
● Prioritize respect & active listening
@nokillwebsites (facebook, instagram, twitter) • 615-825-5608
Every website deserves a “forever home”.
No Kill Websites
A Berry Interesting Production
@nokillwebsites (facebook, instagram, twitter) • 615-825-5608
No Kill Websites
A Berry Interesting Production
WP Beginniner’s WordPress Glossary:
Website project organizer from No Kill:
Follow the hashtag: