I recently left a boutique agency of 5 years and I can definitely resonate with this one. Our agency aimed to catch big fish, and we did, but since they are hard to land we'd pick up small jobs in the meantime, just like the project that you're describing here. In my perspective, this isn't someone deliberately ripping you off. I imagine they intended to ship at the cost they quoted, but the team didn't adjust their working style to match your price point.
All the variations of the logo and design mocks are clearly overkill for a $15k project. The design team had time to fill and wanted to provide lots of options for you to pick from, as they typically would on a larger project. Those variations are an expectation for $100k clients, and you got the $100k customer treatment, but unfortunately not at a discount.
The reality is, small jobs like this are effectively make-work projects for an agency. They typically don't pay enough to be an effective use of time for the agency, but are a way to stay in the black between higher value projects. Small customers become "nuisance" customers as soon as a something better is landed. The team members being swapped out as they are needed elsewhere and newly joining team members then need to re-contextualize and regain momentum, all on your dime.
Your takeaway is correct, don't be a small fish for an agency. If they're busy they won't take your work, and if do show interest, they are desperate for work.
>All the variations of the logo and design mocks are clearly overkill for a $15k project. The design team had time to fill and wanted to provide lots of options for you to pick from, as they typically would on a larger project. Those variations are an expectation for $100k clients, and you got the $100k customer treatment, but unfortunately not at a discount.
Oh, huh.
I was thinking about this as I did the writeup. It didn't feel at the time that they were spending excessive time on the logo variations, but I went back to the notes I took on our first call and realized how out of line all that early work now feels relative to their 30-40 hour initial estimate of the rebrand.
It wasn’t scope creep it was a scam. Shady contractors in every industry pull stuff like this.
They didn’t deliver what you actually contracted for until you put your foot down because that was the hook — they couldn’t keep taking your money if they gave you what you wanted.
For anyone else reading this the best move would be to shut it down as soon as a single minute has been billed for out of contract work: “Hey this is not what I contracted & I won't be paying for any out of scope work.”
Here's the thing I don't get. Did you not have some guarantee of completed work? When they quoted you the $7k, I could see building timeline flexibility into that quote, but I have a hard time imagining building so much flex into the contract in terms of budget that they can hold your work hostage to where you sign the retainer contract. It seems like you should have had some sort of legal recourse to hold them accountable to delivering the promised work in a reasonable time frame before you went the retainer route and found yourself on the hook for an extra $40k. Was there not?
Also, I was surprised by how much you let Isaac get away with. He admitted he badly mismanaged the project, and made decisions that lead to that mismanagement with out consulting you. He badly blew his estimates for you, and was pretty clear that it was his fault. I would have pushed him to eat much more of the losses than he did.
Yeah, it's more of a "highest bidder mentality". That they don't have any experience with hourly billing should have been a massive red flag as that means they need to be very conscious in how they approach the project. That they used this simply as an excuse to deprioritize the project is what caused the problems.
The agency I worked for used to offer a "special" for a brochure site. Basically it was a "website-in-a-day" deal. Customer comes to the agency in the morning, meets with designer and manager, and they agree a design (preliminary work has already been done on a logo). Customer goes for lunch, and the design is handed to two devs. Around 4PM the customer gets sight of what the devs have done, and goes home. The devs work on until say 8PM, and probably put in a couple of hours the next day.
Of course, there was then snagging; it wasn't really a one-day job. The whole deal was pretty inexpensive. We used Drupal with a custom theme.
I don't know whether we made money on these projects, but we did end up with a string of long-term customers.
1) Did you pay everything up front or was it a 50% up front and 50% on delivery basis?
2) Did you manage any deliverables on a google sheet (dates, owner etc) or something similar?
>The reality is, small jobs like this are effectively make-work projects for an agency. They typically don't pay enough to be an effective use of time for the agency, but are a way to stay in the black between higher value projects. Small customers become "nuisance" customers as soon as a something better is landed. The team members being swapped out as they are needed elsewhere and newly joining team members then need to re-contextualize and regain momentum, all on your dime.
Man. That 3rd paragraph resonates so well with me/my employer. We're an industrial automation company. Family owned. Started from the owner's shed and grew to what we are now. We were built on smalltime clients and our product quality got around through word of mouth and are now at the point where we have massive multi-million dollar clients.
We still support the little guys though. And we get more little guys under our umbrella every year. I think there's still a part of our company that recognizes we have roots in helping the farmers automated their cleaner processes. We also have the nearly identical issue that our OP is bitching about: we're married to these massive clients and we fill the gaps with the little projects. But when the timing is getting tight, the little guys are who loses out.
I'm starting to see the cracks. Clients who built our foundations are losing out on support and growth opportunities. We're more concerned with the next mining project or new facility build than we are selling small guys upgrades and ongoing modernization. It's fine as far as the pocketbook goes but I feel like we play a dangerous game allowing our work schedules to be dictated by the big guys. Eventually they all grow to realize the same thing: the controls part is crucial enough to the business that it needs to be brought in house. Once that happens our value falls off quickly. It's only bad because we're losing our core for the opportunity to play puppet to some truly massive clients.
I feel like I'm getting a bit lost in the weeds, but really my point is just how I haven't really thought clearly about what the perception of our business must be to the clients, both big and small. We play a critical service role among many industries but we also run the risk of alienating the business that's virtually guaranteed to be there in hopes of marrying ourselves to somebody who only needs us now, and probably not tomorrow.
If retaining the small clients is a business goal, you should have a (small) dedicated team devoted to them, that knows how to work in the way that these small clients need.
Don't you think that'd become the "B-team" pretty quickly, though? I think it might fall apart. What might also work is something more like the "pro bono" model of lawyers? Make it a marketing thing, maybe see if the big clients would want to get in on the PR benefits of helping the little clients, maybe rotate your rockstars through the smaller projects and help develop less-experienced talent that way?
It has the risk of being a B-team but it's also a good way to onboard new hires. You get a much higher turnover rate of new things to try, do, and learn. One place I worked did communications generation (PDF letters etc), we had massive clients and 300 hour projects and we had 3 hour simple letters. Churning those small ones out was the best way to get me to learn when I signed up. Just as long as someone sensible and experienced is watching. And some people just don't gel well with project marathons - I'm definitely a sprinter who loses focus on huge projects despite my years of experience. I'd rather do a lot of small ones.
It eventually got sold to a bigger more respectable company and those 300 hour quotes crept up north of 1000 hours and it was impossible to finish any job in under 10 hours but that's another story about internal red tape.
Other way around, in my experience. We run a team of ~20 at our studio—the "A-team" all want to work on the smaller projects because they're usually more interesting, they have more control, they get to move faster, etc.
As the owner of a control software company, your explanation about big companies bringing things in-house matches our experiences perfectly, and instead of assuming that they will never be able to bring things in-house due to the niche and a lack of experience, it has inspired me to put some more thought into how to solve this problem as we grow by focusing on having teams dedicated to dealing with and keeping our smaller recurring clients (i.e. have A and B teams as suggested).
> Eventually they all grow to realize the same thing: the controls part is crucial enough to the business that it needs to be brought in house.
I think that creates a narrow operating area for almost all agencies - they need to operate in a narrow gap between "work that isn't valuable enough, so nobody pays for it" and "work that is so important for the business, that they bring it in house".
And you get to play outside this envelope only by finding clients so slow that it takes them years to realize they need an in house team. Now you have a different problem - working for a slow client doesn't push you to get much better.
Yeah, I like the suggestion, I'll preface in saying I'm not in a "Decision Maker" position at my company though so ideas are only so good.
Ultimately it's a management issue. Internally among the techs/engineers we've talked about it but management keeps pushing to satisfy the client and the temporary compromises we make at one moment start to become permanent mainstays of how we operate. I don't have any confidence that if we had a "B-Team" or "Sub-branch" that when a big enough project came along they wouldn't just poach the needed labour and destroy the separation between them.
You could almost say we operate with an "A-Team" and "B-Team" as we have techs split primarily between the Mining and Agricultural clients but they take our techs often from the Agricultural side to fill in on needs of the mining side. There's no shame.
I've been at a small agency that's grown into a midsize agency over the last decade+.
Everything about this story rings true, and the author's conclusions are absolutely on point.
Now our agency is at a place where we can say no to work like this, both because we have a solid client base that supports us financially without projects like this, and because we've learned that no matter how good our intentions, neither we nor our clients are going to be happy with the end result.
All that said, my bigger question is: does the new website bring in more business than the old?
It's certainly better designed, but looking at the copy and IA, I'm not entirely sure that the new site is going to convert better than the old.
To me, the old version was distinctive and unique, while the new looks like basically every other SAAS site designed since the year 2020.
1) How would the old design perform during that time period
2) How would a hypothetical $7k design perform during that time period
#1 is of course why a/b-testing was invented, while #2 is even more speculative. But we don’t know how much of the 66% can be attributed to the new design.
Also the earnings chart shows a clear upwards trend, so 72k is not really an outlier. Fwiw, I liked the previous design better. No idea how the codebase looked like though.
I've worked at small agencies for the better part of a decade and couldn't agree more with this summary.
A lot of the comments seem to take the view that this was some deliberate ploy to overcharge. In reality, it was just poorly managed.
> Small customers become "nuisance" customers as soon as a something better is landed.
My guess would be that when quoted, the project was expected to be completed by a certain date. Because the team failed to adapt, the project overran, new projects took over leaving this one to languish.
Along a similar vein, Sophie Alpert did a talk[1] at React Conf this year on building your own React custom renderer by using implementing the interfaces that React exposes. Sophie explains how you could use React as a declarative API for pretty much any platform if you wanted, similar to how react-native works.
Which is actually a little funny, because that's essentially turning React into a domain specific language for UI rendering. The Racket people are probably facepalming that we had to go via JavaScript and Babel to get to a UI DSL.
It is exactly that, a small library for ui, written in ocaml, ported to a scripting language with immense amount of work, and years and years of educating people with white lies :)
I built a server a few years ago, and I determined it was more cost effective for a drive to fail than to use HGST. It would be more inconvenient, but having a drive fail on a home server with only 6 drives didn't seem very likely anyway.
If you have a 2%/year failure rate per drive, then that leaves you with a nearly 12%/year chance that at least 1 of 6 drives will fail each year. Or a 31% chance that at least 1 of 6 drives will fail within 3 years. Or a 52% chance that at least 1 of 6 drives will fail within 6 years.
Isn't there a cost to time and convenience too? Buying a new disk takes time, as does rebuilding the RAID. And during that time you are vulnerable to another drive failure which could be disastrous if you only have one drive redundancy, especially during the very intensive rebuilding process.
There's also the cost of the time it takes you to replace the drive, get it replaced under warranty, etc. that takes a part of the cost of everything too. I decided that the (at the time) marginal cost of $20/disk was worth my time in likely not having to deal with it.
The article covers the use-case of making small modifications to the build. react-app-rewired[1] and customize-cra[2] give you access to tweak the webpack build indirectly. While babel-macros[3] in CRA 2.X give you access to the babel transpilation step without having to eject. While it's not exactly what you're referring to, it does get you a little bit closer to the build.
Have you explored the mithril.js [1] project? It seems to have reasonably similar goals, although the templating is pretty different from how you implemented it. Mithril doesn't have a concept of state, which also sets it apart from your project, but it seems to handle re-rendering just fine without it.
The problem is that it's not idiot-proof. If someone doesn't understand why the algorithm is important, they might choose none. It's easy to say "they shouldn't be using JWTs if they don't know how to use them", but everyone starts somewhere, and everyone puts stupid bugs into production.
JWT is safe, as long as it's setup correctly, but safe-by-default is a better option.
That being said, I'm not going to swap out my JWTs with PASTs. I know what algorithm I'm using, why I'm using it, it is safe, and I'm verifying them properly.
Rather than maintaining a list of HSTS websites which isn't cross-browser, why is there not an optional HSTS flag attached to the DNS response? I don't know anything about DNS requests, so changing the protocol in a backwards compatible way might be impossible, but that seems like a much better way to maintain that information than with a separate list.
