Recent Insights.

A first-time visitor to your website doesn't read it. They scan it. They make a judgment in roughly ten seconds. And then they either stay or they go. What they're deciding in those ten seconds isn't whether your site looks nice. It's whether this place seems like it understands people like them. Here's what a well-structured site communicates immediately: who it's for, what they need, and why this organization is worth trusting. Not because it says so. Because the structure, the language, and the first thing on the page all point in the same direction. Here's what a poorly structured site communicates immediately: this was built for the people inside the organization, not for the people looking in. The navigation reflects how the team thinks about itself. The hero section says what the organization does, not what it does for the visitor. The most important pages are three clicks down. None of this is a design problem. It's a communication problem that got built into the site. The ten-second test is worth taking on your own site. Open it in a private browser as if you've never seen it. Read only what you'd actually read if you were a first-time visitor. What does yours communicate?

We've started asking clients to tell us about the moment they knew the work was worth it. Not the launch day. Launch days are almost always anticlimactic. You push a button, the site goes live, everyone breathes for a second and then wonders why the inbox hasn't filled up yet. The real moment usually comes later. And it's almost never the thing you expected. A founder tells us she stopped re-explaining what her organization does in every first meeting because the website finally did it for her. An executive director mentions that the quarterly board report came together faster because the team finally agreed on the language they were using. An operations director sends a message six months after the engagement to say that a new hire completed onboarding in half the time it used to take. The process was finally documented. None of these were the headline metrics in the proposal. But they're the ones that stick. The ones that come up in conversations a year later. The impact of getting your digital infrastructure right rarely announces itself loudly. It usually shows up as things that stop being hard. If you're still waiting for that moment, it's worth asking what's in the way.

We hear from a lot of people who've been thinking about reaching out for a while. They're not sure if their situation is the right fit, or they don't want to get on a call that feels like a sales pitch. So here's exactly what happens on a discovery call with us. It's 15 minutes. We spend the first part listening: what's going on, what you've tried, where you're stuck. We're not taking notes to feed into a proposal. We're trying to understand whether this is actually something we can help with. The second part is honest assessment. If we think we're a good fit, we'll say why and what we'd suggest as a starting point. If we don't think we're the right partner for what you're describing, we'll say that too and try to point you somewhere more useful. There's no follow-up pitch if you don't want one. No pressure to decide anything on the call. Most people tell us they leave with more clarity about their situation than they had going in, whether we work together or not. That's by design. If that sounds like 15 minutes worth spending, the link is below: https://buff.ly/LF2XqcG

The operations director at a mid-sized nonprofit came to us exhausted. She wasn't burned out on the work. She was burned out on the overhead. Every week, she was spending hours doing things the systems should have been handling. Manually compiling reports that should have been automated. Answering emails that the website should have preemptively answered. Re-creating documents that should have lived somewhere findable. She knew things were inefficient. She didn't have the bandwidth to fix them because fixing them required time she didn't have. We spent a few weeks mapping what was actually eating her time. Some of it was a website problem. Some of it was a documentation problem. A small piece was a tool problem. None of it was complicated in isolation. It had just accumulated into something that felt overwhelming. Eight weeks in, she sent us a message on a Friday afternoon. She'd taken the weekend off for the first time in months. Not because everything was fixed, but because the worst drains were gone and she could finally see the difference. That's what this work is actually for. Not prettier websites. Quieter Fridays. If you're an operations leader who recognizes this, you're not imagining it. DM me.

A lot of people want to know what it's actually like to work with us before they commit to anything. That's a fair question and we're happy to answer it. The first 30 days aren't about building anything. They're about understanding. We start with a set of structured conversations, with leadership and sometimes with a couple of team members who interact with the digital systems most directly. We're trying to understand not just what needs to be built, but why previous efforts fell short, what the internal dynamics are around the work, and what success needs to look like to be sustainable after we're done. From there, we do our own review: the website, the communications, any documentation that exists around current processes. We're looking for the gaps between what the organization believes its digital presence communicates and what it actually communicates. At the end of 30 days, we present a clear picture of what we found and a prioritized recommendation for what to address first and why. That recommendation sometimes surprises clients. It's almost always more specific than what they came in expecting. No building until we're sure we're building the right thing. That's the rule. If you want to know more about what happens after day 30, we're happy to walk through it. Just reach out.

Scope creep has a reputation for being a project management problem. It isn't, usually. It's a clarity problem that shows up during the project because it wasn't resolved before the project started. It looks like this: a client and a consultant agree on a list of deliverables. Halfway through, the client realizes the deliverables don't actually solve the problem they had in mind. New requests come in. Timelines stretch. Costs go up. Everyone is frustrated and no one is entirely wrong. The root cause is almost always the same: the project started before there was real clarity on what problem it was solving and how success would be measured. Good scoping work is slow. It involves asking uncomfortable questions, like "what happens if we build everything on this list and the problem isn't solved?" and "what decision are you trying to enable with this project?" Most clients haven't been asked those questions before. Most vendors don't ask them because slowing down the start of a project feels like a risk. We think the risk runs the other direction. A project that starts clear moves faster, costs less, and ends with the client getting what they actually needed. Scope creep is a symptom. The cure is asking the right questions before anything is built.

One of the things we've noticed across a lot of different engagements: the way an organization onboards a new client or partner is one of the clearest signals of how healthy its communications infrastructure is. When the process is smooth, it usually means a few things are true. The organization has a clear, consistent way of explaining what they do and what to expect. Information is in one place and accessible to the people who need it. Staff can answer common questions without hunting for the answer or forwarding an old email chain. When it's rough, when new clients feel confused, when internal staff give slightly different answers to the same question, when the same explanations have to be repeated each time, it usually points to a gap in the underlying system. Not a people problem. A structure problem. We've started including onboarding as a diagnostic question early in engagements. Not because we're going to redesign the onboarding process (though sometimes that happens), but because it quickly reveals whether the communications infrastructure can support what the organization is trying to do. Most of the time, the problems people think are marketing problems turn out to be communications problems. And communications problems are solvable.

There's a pattern we see often enough that we've started naming it in early conversations with clients. An organization launches a new website. There's real energy around it. The team is proud of it. They post about it. Leadership mentions it in meetings. Then six months go by. The blog that was supposed to publish monthly has two posts. The events page still shows something from last quarter. The staff page has three people who no longer work there. The homepage headline, which was carefully workshopped for hours, now describes a service the organization has pivoted away from. It's not negligence. It's capacity. Nobody planned for the ongoing work because the project was framed as an event, something you do and finish, rather than a system you maintain. The organizations that avoid this cycle do two things differently. They plan for content and maintenance before launch, not after. And they build the site using tools their team can actually use without a developer, so updates happen when they need to instead of when someone has time to file a ticket. If this sounds familiar, you're in good company. It's one of the most common things we help organizations recover from. And it's almost always fixable.

The About page is usually the second or third most visited page on any organization's website. It's also almost always the most neglected. Most About pages read like a résumé. Here's when we were founded. Here's our mission statement. Here are our staff bios. Here's a photo of the team at a retreat two years ago. None of that is wrong. But it's answering the wrong question. Visitors land on your About page because they're trying to figure out if they can trust you. Not just whether your organization exists and has a mission, but whether the people behind it understand the kind of problem they're dealing with. Whether you've done this before. Whether working with you would feel like a partnership or a transaction. A good About page makes that case. It tells a story about why the work matters and how you approach it, in language that feels like a real person wrote it, not a committee. It gives visitors something to connect with before they ever get on a call. If your About page is mostly logistics, it's probably losing you conversations you don't even know you're missing.

Most organizations we talk to have never done an accessibility audit of their website. Most also assume it isn't something they need to worry about. Both of those things are worth revisiting. In the US, the Americans with Disabilities Act applies to many types of organizations, including nonprofits and service businesses, and legal cases involving website accessibility have been increasing steadily. The organizations that get caught by this almost never knew they were at risk. It usually isn't a target. It's an audit, a complaint, or a legal notice that arrives without warning. Beyond the legal exposure, accessibility is also a performance issue. Websites built to accessibility standards tend to be faster, cleaner, and easier for everyone to navigate. Screen reader-friendly structure is usually just good structure. High-contrast text is usually just readable text. Clear heading hierarchy benefits every visitor, not only users with disabilities. The organizations we work with often assume accessibility is expensive to retrofit. Sometimes it is, when it's been neglected a long time. When it's built into the design and content decisions from the start, the cost is low and the benefit is real. If you've never done an accessibility review, it's worth knowing where you stand. Not just for legal reasons. An inaccessible site is usually one that's harder for everyone to use.

One of the questions we ask early in any engagement is: what are your workarounds? Every organization has them. The spreadsheet that technically replaced the CRM but nobody's updated in six months. The shared Google Doc that's the unofficial source of truth for something the website should probably handle. The email thread that gets forwarded every time a new person needs to know something. Workarounds aren't failures. They're usually smart, practical responses to a gap in the system. But they're also a map of where the friction is. When we find a cluster of workarounds in the same area, it usually points to something that was built without fully understanding how the team would actually use it, or something that was never really built at all and has been duct-taped together over time. The good news is that workarounds are often fixable once they're named. The bad news is that most organizations have stopped noticing theirs. They've become part of how work gets done, and the cost is invisible until someone new joins and says "wait, why do we do it this way?" If you can name three workarounds your team uses without thinking about it, you already know where the work is.

When organizations ask about the ROI of a digital project, they're usually thinking about website traffic or lead volume. Those things matter. But they're rarely where the real return shows up first. The return we hear about most often is time. A staff member who used to spend two hours a week answering the same questions by email because the website didn't answer them. A program director who rebuilt a grant application from scratch each cycle because the content wasn't organized anywhere accessible. An executive director who rewrote the organization's description every time someone asked for it because there was no agreed-on language anywhere. When a digital system is built thoughtfully, these friction points go away. Not dramatically. Quietly. Things that used to take an hour take fifteen minutes. Decisions that required three people get made by one. New hires get up to speed faster because the information is somewhere findable. None of that shows up in an analytics dashboard. But it's real, it compounds, and it's often where organizations feel the investment most clearly. The traffic metrics matter. But if that's the only lens you're using, you're probably underselling what's actually possible.