Category: Product Development

Why it ain’t cheap, and how it could be…

The market rate for a simple but custom brand website from a boutique agency typically lands around $50-80k.

How do I know? I’ve got about eight years of agency experience; I’ve managed budgets and seen plenty of proposals sent and SOWs signed. I’ve also been on the other side and led digital vendor procurement for small and medium organizations – drafting RFPs, reading through proposals, and awarding contracts to the most impressive agencies. I’ve seen enough of that $50-80k range to vouch for it. But I can also vouch that it is WAY. TOO. MUCH.

It’s definitely not in my interest to devalue website work. I’ve had my fair share of frustrations as a former freelancer who was once resigned to taking every lowball gig I could find, doing full-service site designs & builds for damn near minimum wage.

But we should break down that $50-80k range…

As of 2024, the Bureau of Labor Statistics placed the median pay for web developers and digital designers at $95,380 (about $46/hour). So, as a freelancer, if I were charging a “market rate” for a simple web project (which I estimate at 60-120 hours), I would end up billing at or below the $5k range when all is said and done. But let’s say I price myself 2x higher, because freelancers cost more, and then I add another 1.5x, because I have 10+ years of experience and know my worth. So now we’re at almost $17k. But even my inflated invoice is less than half of the lowest price point on the agency range.

So how do agencies get by quoting so much for small web projects, and why are organizations okay with budgeting for such high estimates?

When you’re paying for an industry standard website from an agency, this is where your dollars are going:

• Overhead costs. Most obviously, it costs money to run a business. When you hire an agency with a sizable team, those costs (equipment, office space, taxes, licensing, insurance, admin, etc) are built into the rates they charge you. Standard business advice suggests that reasonable overhead lands at 25-30% of revenue, and agencies bill accordingly.
• Team overload. Agencies tend to show involvement by assigning an entire team to your project – many with nebulous roles like account manager, client engagement lead, strategist, delivery lead, and a couple project managers to wrangle them all. On the client side, it looks structured, and that feels safe. But a team that size comes at a cost, and for a basic site, it’s probably not necessary.
• Handoff tax. With a bigger team, you’ll also end up paying for bureaucracy over quality. At larger agencies, discovery, UX, design, and dev are typically separate lanes managed by process leads. Every handoff adds time, cost, and risk. I’ve seen pixel-perfect builds ship with missing CMS flexibility because the editor requirements died in the transition from design to engineering.
• Over-definition. Larger teams also lead to more in-depth discovery phases and elaborate roadmaps. These can look impressive on paper, but for a basic site, they run the risk of over-complicating things. I’ve sat through weeks of workshops for a single landing page, only to lock the team into a rigid content model that nobody could edit later. You could end up paying twice: once for the sessions, again to undo the over-definition.
• Process theater. Process is a huge part of the agency performance. It can feel tangible and reassuring to have multiple checkpoints, alignment sessions, discovery decks, and detailed project tracking sheets – these added layers of management and documentation create a sense of project progression. But let’s be real: most clients never look at those deliverables. They’re billed for five hours for more emails to bury in their inboxes. All that structure comes with cost and clutter.
• Excessive tooling. Agencies love to pitch custom design systems and complex builds because they sound impressive on paper and boost their portfolio cred, but in reality, they can slow you down. And when multiple developers touch an over-engineered site, inconsistencies pile up fast, creating tech debt that makes every future change harder. This raises your dependency on developers and potentially locks you into costly infrastructure. Unless you need an app with complex integrations, stick to a mainstream platform with editor-friendly blocks.
• Mandatory maintenance. Lastly, agency projects often come with an upsell in the form of a post-launch retainer, which becomes a necessity if your end product is a complex build with rigid templates. But the problem with maintenance retailers, especially for smaller accounts, is that agencies tend to deprioritize them. This means tickets may sit at the back of the queue, and a simple update could take weeks to reach production.

Free RFP Template

Calling out overpriced web work isn’t about devaluing the labor – it’s about building price transparency. And you need to decide if the large team and process-focused work is a good fit for your organization. Sometimes it do a good job of mirroring the bureaucracy of larger organizations, so it works. But for most small and mission-driven organizations, a $50-80k production is neither necessary nor wise to get a brand website that’s both usable and accessible.

Small organizations need a lean partner, a practical scope, and autonomy, and the traditional agency model is simply misaligned with those needs. Our nonprofit RFP template helps you define ownership and outcomes clearly, so you don’t need layers of middlemen to translate your needs. Use it to find a focused, independent partner that can outperform every time, so you can free your budget for the work that really matters.

I made a budgeting app…

How many times have I sworn I’d start budgeting, made a convoluted spreadsheet or downloaded some fancy app, tinkered around with it for a couple hours, and then never touched it again? It took me most of my self-supporting life to finally actually commit to keeping a budget. That’s like…two decades, but I found a tool that works for me. I made it myself.

We’re constantly reminded that we live in a culture of short attention spans and instant gratification. Social media content is there for a quick hit; shopping apps operate on 1-button checkout and delivery in hours. Why don’t budgeting apps follow this trend? Most of the top tools out there are bloated with dashboards and features that demand you sit down for hours to map out at least a month in advance. But who has the time, foresight, or mental bandwidth for that kind of planning?

Having tunnel vision for the short-term makes sense in this economy where everything feels temporary and unstable – jobs, housing, benefits, even health. How can one project 30 days out if even the next 24 hours feels in flux? Even for those in stable positions, the threat of economic uncertainty feels like it could be just around the corner. Long-term planning seems to offer few real guarantees.

Still, most budgeting apps are built with pre-existing financial stability in mind. They cater to users who already have steady paychecks, routine expenses, and a comfortable buffer between income and bills. They’re built to help with things like fine-tuning savings goals, tracking discretionary spending, or planning for future vacations. These features assume you already have money, not that you’re trying to figure out how to hold on to it.

YNAB, for example, asks users to allocate their income into top-level categories – bills, needs, and wants – and then into neat little subcategories like rent, groceries, self-care, and travel. But for people who see their finances through a paycheck-to-paycheck lens, spending often spikes right after payday and tapers off as money runs out. The way I see it, category-based forecasting doesn’t aim to change that habit, it only spreads it out. Not to mention that if your income isn’t stretching far beyond the basics, you don’t have much to allocate in the first place. Across the board, budgeting apps also tend to require connecting bank accounts, paying subscription fees, and figuring out complicated dashboards. For apps with more complex data functions, the learning curve can be steep.

But what about people working irregular hours, getting paid in cash, and living off thin margins? What about people who simply don’t have the time to set aside each month to plan out their financial projections in speculative detail? When it comes to budgeting, managing wealth and navigating precarity are two entirely different missions, and should be approached as such.

---

What could a more effective budgeting tool look like?

Here’s what I believe:

• Budgeting should be daily. Daily insights are what people need when conditions change fast. It should be able to answer the question, “Can I buy this today and still be okay a few days from now?”
• Privacy should be the default. No logins, no account linking, no hidden data capture.
• Accessibility should be core. It should be offline-friendly, mobile-first, and most importantly, free.

These aren’t just ideals. They’re design choice that are the foundation of the humble but useful budgeting tool I made myself called dailyallowance.

Contrary to what Big Tech has allowed us to believe, useful apps don’t need to cost. Massive server farms, complex data pipelines, or pricey legal and third-party service agreements are not necessary when users own and store their own data locally on their devices, and profiting off sales or ad revenue isn’t a hidden core function. dailyallowance is lightweight, intentionally free of bloated integrations, and designed to run without tracking, syncing, or subscriptions.

---

Install dailyallowance

dailyallowance is a Progressive Web App (PWA), which means you don’t need an app store account or a subscription to get it. It installs directly to your phone in seconds.

How to install the app on your phone:

On iPhone (Safari):

1. Open budget.tomcatlabs.com.
2. Tap the Share button (square with arrow) in the bottom middle.
3. Select Add to Home Screen.

On Android (Chrome or Firefox):

1. Open budget.tomcatlabs.com.
2. Tap the three-dot menu in the top right.
3. Select Add to Home screen or Install App.

The app runs locally on your device, so you can open it offline.

“Driving alignment”, or just doing the executive team’s bidding?

In modern tech companies, the Product Manager has become one of the most coveted and well-compensated roles. At many major tech companies, Product Managers (PMs) earn higher salaries and are framed as influential leaders, often described as the “CEO of the product” (yet, oddly enough, they don’t tend to hold direct authority over anyone). On paper, PMs are tasked with high-level decision-making, aligning cross-functional teams, and delivering business value. But beneath these ambiguous job descriptions lies a question that many (including myself, with eight years of PM experience) still wonder: What exactly does a Product Manager do?

Unlike other product team members – engineers, designers, researchers – whose roles are rooted in tangible deliverables like code, wireframes, or data insights – the PM’s outputs often remain abstract: translation, prioritization, synchronization. A PM’s tangibles might look like a roadmap, a backlog, lists of KPIs and OKRs… but these are deliverables of process, not product.

The PM today functions as an intermediary between executives and the teams who build, maintain, sell, and use the product. Sitting in the middle of different teams with different projects, timelines, and priorities, a PM ensures everyone is moving forward toward the same goal. But why is this coordination even necessary?

Imagine an e-commerce company where the marketing team is setting up a seasonal promotion. Maybe design is updating site visuals to improve CTA’s, and engineering is fixing a bug to improve checkout flow. Meanwhile, customers are asking for subscription-based options to make repeat orders easier. All of these objectives point toward the same outcome – improving customer experience and increasing conversions. Because these are not conflicting goals to begin with, shouldn’t they, in theory, coexist without the need for a role tasked primarily with driving alignment?

In practice, these teams don’t typically move as one. Even when they’re all working toward the same broad outcome, they tend to operate in siloes, where lack of shared context and real-time communication means redundancies form and opportunities get missed. A PM can play a vital role in timing and coordination.

However, that need isn’t organic; it’s structural. It’s a direct result of an organization where decision-making has been isolated from implementation, and communication is flowing up and down rather than across. The need for a PM then only exists because of this hierarchical structure where strategic direction is set from the top, and execution must then be distributed across its disconnected teams.

Now imagine in the e-commerce company that leadership has stepped in with a new mandate: “Break into a new market by the end of Q4.” Suddenly, each team’s efforts must serve this singular, timeboxed executive vision. Marketing’s promotion needs to shift if it doesn’t target the new audience. Design’s visuals must reflect a new brand voice. Engineering’s bug fix must consider new user behavior. A new order offer must appeal to potential customers over current customers. Someone is needed to translate, enforce, and prioritize this on behalf of leadership. That’s where the PM steps in.

Now, just as much as the PM is there to deliver these leadership goals to teams, the PM is also supposed to communicate team realities upward. Maybe implementing a new market plan disrupts current efforts that are already driving growth. Maybe the timing is simply too tight. Ideally, the PM could help leadership weigh these tradeoffs, but within the PM’s intermediary function is a structural contradiction. Is it possible to represent diverse teams when proximity to power biases PMs toward executive priorities? In this context, the PM role begins to function more like middle management: accountable upward, while only loosely connected to the realities of day-to-day operations. “Driving alignment” begins to really mean “getting everyone to execute leadership’s vision without resistance.”

This isn’t to say that PMs are consciously complicit in this system. Many, including myself, may approach the role with hopes of driving collaborative power and championing innovative ideas. But the rise of Product Management in its current form reflects a deeper tension in tech: the need to further drive the wedge between product teams and executives. Rather than shifting organizational structure to be more horizontal, companies are more focused on creating senior-level roles that drive insulation over innovation.

If companies were structured more laterally, then the need for a central figure to “drive alignment” would shrink. Coordination would be built into the process, strategy would be co-developed, and information would be transparently shared. If tech is to become more equitable and community-led, the PM role might look entirely different, or disappear altogether. Product planning that is grounded in collective ownership probably wouldn’t necessitate adding a layer to act as translators of executive will, because there would be no executive will.

So where does that leave the question of what exactly a PM does, or could do?

I value coordination, but not when it reinforces hierarchy. My hot take is that product management should be about building spaces where alignment emerges organically. In a way, they should strive to make themselves less essential. As a role often classified as “generalist”, PMs possess – or should possess – the ability to shift from managerial bottleneck to hands-on contributors across diverse teams – stepping in to write copy, sketch up a wireframe, update a graphic, or fix a bug. All while recognizing that the PM role needs to be deliberately replaceable by design if the role is truly fostering the collaboration needed to build resilient teams. In doing so, PMs bring cohesion across functions not by directing from above, but by actively working alongside their teammates.