Controversial Opinions
Things we believe that might ruffle some feathers. We're not trying to be contrarian for its own sake—these are hard-won lessons from years of watching projects succeed and fail.
Most AI Projects Shouldn't Be Built
At least not yet.
We make money building AI solutions, but we'll be the first to tell you that most AI projects are solutions looking for problems. Before you automate something, make sure it's actually worth automating. (Or possible to automate.)
Sometimes a spreadsheet, a checklist, or just hiring another person is the right answer. We'd rather lose a project than build something that doesn't deliver real value.
Outcome is the only thing that matters.
EVERYTHING else is a detail.
Us nerds can get caught up in the details of how things are built. Like connoisseurs of fine code we can endlessly debate the best way to do something. But at the end of the day, a beautiful piece of code is worthless if it sucks to use.
Enterprise Software Is Usually Terrible
Complexity is not a feature.
Most enterprise software is designed to be sold, not used. It's packed with features nobody needs, requires months of implementation, and ends up being worked around rather than worked with.
Simple tools that do one thing well beat complex platforms that do everything poorly. Your team will actually use them.
Meetings Are Where Work Goes to Die
If it could be an email, it should be an email.
The default response to any problem in corporate America is to schedule a meeting. Most meetings exist because someone didn't want to make a decision or write something down.
We bias heavily toward async communication and written documentation. When we do meet, it's because we need to actually discuss something, not because it's Tuesday at 10am.
Perfect Is the Enemy of Done
Ship it. Learn. Iterate.
We've seen too many projects die in pursuit of perfection. Six months of planning, endless stakeholder reviews, and comprehensive documentation—followed by a launch that flops because nobody actually used the thing until it was "ready".
We'd rather ship something rough in two weeks, learn from real usage, and iterate. You'll end up with a better product faster, and you'll waste less money on features nobody wanted.
Most Best Practices Aren't
Context matters more than convention.
Best practices are usually just "practices that worked for someone else in a different context." Blindly following them without understanding why they exist leads to cargo cult engineering.
We think from first principles. Sometimes that means following conventions. Sometimes it means ignoring them entirely. The goal is solving your problem, not checking boxes.