Forem: Charpie

🔥 Insane CTO Tries to Install His Own Product While Doing the Spicy Noodle Challenge 🔥

Charpie — Wed, 18 Jun 2025 16:45:12 +0000

Don MacKinnon, CTO of Searchcraft, tries to complete the Spicy Noodle Challenge while building a search app from scratch.

Featured:

Searchcraft - https://searchcraft.io/
Searchcraft Vite Template - https://github.com/searchcraft-inc/vi...
Searchcraft Docs - https://docs.searchcraft.io
Searchcraft Discord - https://discord.gg/y3zUHkBk6e

40+ MCP Search Tools

Charpie — Thu, 12 Jun 2025 21:43:31 +0000

We just added over 40 tools to the Searchcraft MCP server.

For those unfamiliar, Searchcraft is a next generation search tool for developers. We're built in Rust. Our aim is to make search lightweight, fast, and relevant without devs requiring deep Elasticsearch or devops knowledge.

Utilize Searchcraft in your RAG pipelines or as its own feature.

With this update, you can self-host Searchcraft (download via Docker) and configure your integration with tools like Claude Desktop.

If you have questions, comment below or join our Discord server.

Building Spacescrapers

Charpie — Wed, 11 Jun 2025 17:01:31 +0000

Project Management in Action, not Motion

Delivering complex digital assets isn’t difficult if you know where to focus your team.

For many department leads, producing a website or app (or overhauling an existing asset) can feel like facing Goliath. With the right strategy, though, it’s possible to shift your mindset to a project management system that’s immediately rewarding.

Whether you’re a CEO, project manager, team leader, or engineer, it’s often easy to feel like you are outside the realm of your expertise when planning technical projects, and it’s possible you are. These things require teams of people to get right, each with their own specialty. Before you know it, you’re a hardhat-clad contractor organizing the construction of what feels like something beyond a skyscraper. In front of you, ideas and chicken-scratch blueprints for a daunting behemoth that stretches beyond the clouds, beyond the atmosphere, and into an infinite, inky vacuum—a spacescraper, if you will.

You don’t have to be a mastermind engineer to construct spacescrapers. We’ve all faced tasks that seem insurmountable. Up until this point we’ve likely developed methods of our own to start chipping away the boulders before us, yet I still see many spinning their wheels and struggling with the stress of large tasks every day. These battles don’t just make for grueling journeys, they usually prevent the journey in the first place because focus is concentrated on motions directed at the final outcome instead of action that results in measurable progress.

In Atomic Habits, author James Clear defines his view on the difference between motion and action:

“When you’re in motion, you’re planning and strategizing and learning. Those are all good things, but they don’t produce a result.

Action, on the other hand, is the type of behavior that will deliver an outcome. If I outline twenty ideas for articles I want to write, that’s motion. If I actually sit down and write an article, that’s action.”

Remove obstacles and barriers to entry by streamlining motion and making room for more action. Going through the motion is important, but it can be mistaken for progress. It’s merely a minor prerequisite. It’s buying the book and showing up to class, but it’s not doing the work that shows progress.

If we want to accomplish large tasks, like building spacescrapers, we must make room for energy that can be put toward producing results, not planning results. After all, this is a digital space. If we want to start with brick and swap it out for glass later, we can, but we can’t apply new knowledge without laying that first brick.

But what about the importance of planning and having a solid foundation? Of course the value of having a plan and a solid foundation is indisputable, but we can be smarter about this process. Timebox your intentions in motion. Make them efficient and avoid spiraling into hypotheticals. These motions must lead to action quickly.

Intentions in Motion vs. Action

Those trying to build a spacescraper with intentions in motion spend time talking about what they’ll be able to do with their completed masterpiece. They'll list the benefits of the achievement and the challenges over which they became victors. They’ll spend hours, hundreds of hours, molding and sculpting the pièce de résistance to frame it on a gallery wall and gain support and acknowledgment from an internal team. What-will-ultimately-be is measured in hypotheticals tainted in confirmation bias. All the while, a dirt lot remains in public space.

Meanwhile, those with intentions in action have built the first floor of their spacescraper. They don’t care what it looks like, they’re building to learn and gain further insight into where they’re headed. They’re standing on top of the first floor and getting a better view of the land and using that initial knowledge to inform the succeeding floors. Each floor informs the next and progress is measured in floors completed and insight gained immediately rather than one spacescraper completed years from now whose benefits were defined in an echo chamber.

If you want to make progress in your next technical challenge, set aside the end goal.

Start Before You're Ready

Popular YouTube content creator Sean Cannell often urges his viewers, who are themselves aspiring creators, “Start before you’re ready.” The Think Media founder and CEO embeds the phrase throughout his online videos repeatedly, as if it were a mantra (and it should be), committing it to method and cementing the idea into the foundation of any potential urge to create, whether it’s posting new content or starting a new exercise regimen.

The great can wait; don’t let perfection become a barrier to your value.

“The best is the enemy of the good.” Voltaire.

Easier Said than Done

If you’ve already been tasked with constructing that spacescraper, I can practically feel the dismay building as you read.

“Easier said than done,” you might be saying to yourself. “How can I start before I’m ready if I don’t know where to begin?”

If the starting point is unclear and you don’t know where to begin, that’s easy, because it means you don’t have enough information. If you don’t have enough information, then your starting point assumes the role of hunting and gathering more information. You’re on a mission for data.

If the goal is overcoming a particular business challenge, the data you’re looking for are informed by two queries:

What strengths and opportunities may exist to achieve the goal?
What threats and weaknesses are present that are keeping the orgaization from achieving the goal?

When building digital experiences, our progress is measured in small actions that generate user behavior data. This is what could be defined as a lead measure, but that’s for another day. By continually producing smaller actions, we’ll generate more data and gain more insight to inform future action.

We don’t participate in massive unveilings or pull the velvet after months of hard work. We make small, meaningful changes, frequently. Before you know it, we’re checking out the view from atop hundreds of floors of knowledge produced in action—primed for the next informed evolution.

Originally published on searchcraft.io.

[Boost]

Charpie — Tue, 03 Jun 2025 21:09:09 +0000

Don MacKinnon

Jun 2 '25

Make the Developer Experience Good

#productivity #programming #frontend #startup

Comments

1 min read

The Quiet Revolution of Empowered Workers

Charpie — Tue, 03 Jun 2025 04:10:22 +0000

Factory-Floor Lessons in Reshaping Software Innovation

‍Hierarchy on the Floor

In the early 20th century, manufacturing was organized with a rigid hierarchy. Managers and engineers made all significant decisions, while front-line workers were expected to "do as they're told," performing narrow tasks without input into process or strategy. Factory workers, often seen as low-status laborers, had little agency beyond their assigned duties. This division meant that problem-solving and innovation were the sole province of experts and senior staff, not the rank-and-file. By the 1930s, the typical American steel mill or machine shop exemplified this top-down structure. Workers on the shop floor desired better pay and conditions, but companies struggling through the Great Depression had slim margins. Management's stance was traditionally paternalistic at best and authoritarian at worst, with executives reluctant to share decision-making power. The prevailing belief was that only managers and specialized industrial engineers could improve production methods; the role of the average worker was to follow orders. Any initiative or creative insight from a line worker was more likely to be ignored than welcomed in this era. This was the original context of strict divisions of responsibility that set the stage for a dramatic change.

Crisis Ignites Radical Change

A pivotal catalyst arrived in 1938 at a small steel mill in Ohio on the brink of closure. In this dire situation, an unconventional partnership formed between management and a labor leader named Joseph "Joe" Scanlon. Scanlon, an ex-boxer turned steelworker and union local president, was convinced that the workers themselves held untapped knowledge and ingenuity that could save the failing plant. Management, desperate to reduce costs and improve efficiency, agreed to try something radical for the time: involve the shop-floor workers in solving the company's problems.

Scanlon organized joint worker-management committees tasked with brainstorming and implementing production improvements. This approach reversed traditional roles, inviting blue-collar workers into discussions once reserved solely for engineers and supervisors. The concept was simple yet profound: workers would receive profit-sharing bonuses, incentivizing them to use their hands-on experience to suggest practical improvements.

Technological factors also played a role. By the late 1930s, manufacturing methods had become more systematic, making it easier to measure productivity gains. This allowed transparency into the impact of improvements. Additionally, the societal environment, particularly the approach of World War II, prompted industries to maximize their output. These pressures made management more open to new ideas, even if it meant breaking the old hierarchy. In 1938, Scanlon famously negotiated a union-management productivity deal: if costs per unit fell below a set norm, the company would share the savings with the workers as bonuses. Almost immediately, the benefits of giving front-line workers agency became evident.

Scanlon's plan quickly demonstrated its worth. One early committee suggested equipment improvements costing $8,000 that delivered an astonishing $150,000 in savings the first year alone. Workers, previously disengaged, began proactively addressing issues such as production bottlenecks and quality control, knowing they shared directly in the plant's success. A sense of shared purpose emerged, fundamentally transforming the workplace.

The long-term outcomes of this shift in responsibility were resoundingly positive on multiple fronts. First and foremost, there were dramatic improvements in efficiency and quality. At Parker Pen, within 20 months of launching the worker-participation plan, production output surged by 61% (via Time). Across the various factories that adopted the Scanlon Plan (as it came to be known), similar trends were observed. The Scanlon Plan truly deserves a deep dive on its own, but what relevance does this historical industrial shift hold for today's software developers?

Aesthetics to Architecture: The Evolving Role of Front-End Developers

The story of these 20th-century factory workers carries strong echoes in today's tech industry, especially in the evolving role of the front-end developer. Not long ago, front-end web developers were sometimes perceived as the "pixel pushers" of software teams tasked with translating a designer's mockups into code. At the same time, the "real" architecture and business logic were handled by backend engineers or more senior staff. They were the "last mile" of an application, translating data into delightful user interfaces. In other words, front-end developers were viewed as peripheral executors rather than strategic contributors. But much like the steel mill workers of the 1940s, who stepped up to improve production, modern front-end developers have rapidly expanded their agency and responsibility, yielding hugely positive results.

Today's front-end devs often operate as de facto full-stack engineers and architects. They are expected not only to build interfaces but to shape the application architecture and influence key technical decisions. As web pioneer Chris Coyier observes:

"There's a pile of new stuff we're now expected to do, particularly if we're building a site with a modern JavaScript framework."

Modern front-end developers find themselves managing state, orchestrating data fetching, and optimizing performance in ways that once belonged firmly to the backend domain.

This shift mirrors the earlier factory-floor transformation, where workers leveraged their hands-on experience to suggest and implement meaningful process improvements. Similarly, front-end specialists now leverage deep user insights to drive innovation, identify UI issues, optimize user flows, and proactively implement enhancements that directly impact business outcomes.

The drivers behind both shifts are remarkably similar. In manufacturing, technological advancements and societal pressures enabled worker empowerment. In software, the increasing availability of sophisticated, accessible tooling, matched with consumer expectations for premium experiences, has elevated front-end development from those once peripheral conversations to real, tangible strategies. Today's cross-functional teams further reinforce this empowerment, providing front-end developers and even designers with direct opportunities to influence strategic decisions and innovate continuously.

Empowering Teams and Accelerating Innovation

Front-end-first projects demonstrate that developer empowerment directly leads to business outcomes. Product owners see faster iteration cycles and more experimentation. Engineers are happier and more productive working with higher-level tools. And end-users get a better, more responsive experience. Organizations that enable autonomous teams (with full-stack ownership, including the front-end) see significantly higher product throughput and customer satisfaction, making the strategy a competitive advantage.

For business leaders and executives, the implications are exciting. Adopting a front-end-first model accelerates product development, fosters autonomy, and enhances user satisfaction. Small, agile teams equipped with advanced tools can rapidly deliver world-class features previously achievable only with significant resources.

Companies can experiment, learn, and improve their information delivery in near real-time, keeping them one step ahead of customer expectations. The front-end-first approach fosters a culture of innovation—proving once again that true progress always begins by trusting those closest to the work.

Sources

"Management: The Scanlon Plan" Time

"Scanlon plan" Wikipedia

"When frontend means full stack" by Chris Coyier

Originally posted on Searchcraft.io.

The Famous Experiment

Charpie — Sun, 01 Jun 2025 23:22:13 +0000

Originality is Inevitable

In 1638, Galileo theorized a column of water descending in a tube, sealed at the top, would create a vacuum in the space above it. In his theory, the force of the vacuum was responsible for suspending the water within tube, keeping it from rushing out into a basin of water below.

To translate: Think about performing a similar experiment as a kid when you magically suspended orange soda within a plastic straw just by holding your finger to the straw’s top opening. Now multiply the scale of that experiment by 48.

Galileo’s colleague, Giovanni Battista Baliani, was in disagreement as to what kept a 32 foot column of water in a sealed tube from dispersing, theorizing the column was held together by the weight of the air around us as opposed to a force created by a vacuum.

Baliani’s theory inspired another young Italian physicist and student of Galileo, Evangelista Torricelli, who sought to re-create the experiment and land on his own conclusion. In 1643, just five years later, Torricelli’s attempts led to the use of mercury in place of water, which allowed the experiment to be performed at 1/14th scale. Needing only two-foot tubes, Torricelli could easily perform the experiment in public venues and bring it to other physicists. The experiment’s mobility enabled it to catch fire within the scientific community. It quickly became a catalyst for modern experiments as physicists around the world began producing their own versions and passed it from one to another like a game of telephone, replacing one variable for another—and so forth. Torricelli’s experiment was so popular it became known as the “Famous Experiment” when described in 1654, which is the first known use of the phrase in recorded English. Later, in 1663 it would be described as “famosissima” in Italian.

Torricelli’s Famous Experiment went on to conclude that there was indeed a vacuum, as Galileo theorized, but that air surrounding the column of water and pressing on the basin of water below was, in fact, having an impact as well. Further examination and study proved air has weight, and Torricelli went on to write, “We live under an ocean of air.” It was the Famous Experiment that led to Torricelli’s invention of the barometer in 1644, one year later, and would ultimately revolutionize atmospheric science forever.

Torricelli never began his experiments intent on changing the world forever. He didn’t know he’d ultimately invent the barometer. The original experiments themselves weren’t even of his own creation, yet the sum of his past experiences and individuality inevitably led to an original conclusion. He started precisely where others had, but landed somewhere new, somewhere exciting, and somewhere nobody had ever been. Perhaps originality is inevitable and, if so, should never be a barrier to exploration.

Weather apps abound.

As of this writing there are 8,210 weather-related apps in Apple’s App Store marketplace. The Google Play store has 9,835 apps that let you know if you’re going to need an umbrella today. Day by day, these apps seem to multiply. The sheer amount never seems to deter creators from producing the same solution over and over again, at least on the surface. But what is the attraction?

Perhaps a more poignant question is, “Does the attraction matter?” It’s possible that thousands of creators simply started in the same place, embarking on a weather app, in hopes that new discoveries along the way would lead them somewhere they wouldn’t have thought of had they not put one foot forward.

When you’re in the business of software development, daily requests flock into your neighborhood from those with app ideas. Nearly everyone has an app idea, just as everyone has some idea for an invention, and we’ve all got some form of story with the quotes: “That was my idea!” Or “Hey, we thought of that!”

Often, the excitement around an app idea or invention flutters away as quickly as a search engine reveals that it’s not original, it’s already been done... many, many times. When years’-old ideas show up in the wild, produced by someone else (Liz Gilbert calls this “Big Magic.”), it can spark a sense of shoulda-coulda-woulda and the dream dies then and there. But, it shouldn’t. Everyone is unique; we are made of the culmination of our own experiences—all of which affect our output. Pushing forward will undoubtedly produce a different outcome, even if it’s ever so slight.

Weather apps alone should be inspiration enough to move forward with a desire to create. Thousands exist, all of which stem from a common idea, yet few look exactly the same and some have even led to truly unique ideas and advances in human interaction.

Take, for example, Dark Sky, a weather app originally released in 2012 for iOS and Android after a modest Kickstarter campaign. At first glance, Dark Sky looked to accomplish what most in the genre provided, a reliable forecast, but founders Jack Turner and Adam Grossman uncovered a rather specific niche along their journey—keeping Dark Sky’s users dry. Turner and Grossman focused their energy on creating algorithms that crunched government precipitation data in a way that could potentially provide up-to-the-minute storm prediction. Unlike traditional weather apps, Dark Sky put aside conventional priorities in seven and 10-day forecasts for an app driven to help users in the immediate future. It wasn’t long before Dark Sky’s unique approach turned it into an instant success and allowed the app to grow a user-base over eight successful years before attracting the eyes of Apple, who acquired Dark Sky in March of 2020.

Much like Torricelli’s Famous Experiment, the goal of originality has not been a barrier to entry for weather apps but rather originality has become an inevitable byproduct. Torricelli could not have known he’d invent the barometer when re-producing Galileo’s experiment, but he persevered solely on a hunch that his outcome would be unique. Similarly, Turner and Grossman couldn’t have predicted their idea would be acquired by Apple when they set out on a journey thousands had before them.

If you’ve got an app idea, a dream, and a hunch, then move forward! Do not let the landscape before you discourage what might be. You’ll likely end up somewhere you didn’t expect, somewhere exciting, and perhaps somewhere nobody has ever been.

Sources

Big Magic by Elizabeth Gilbert, Penguin Random House (published by Riverhead Books)

The Invention of Science: A New History of the Scientific Revolution, Harper Collins

History of Barometer, Soft Schools

Evangelista Torricelli, Wikipedia

Video: See How Dark Sky Disrupts The Weather Report With Its Mobile Tech, Fast Company

Originally posted on Searchcraft.io.
‍

Plug-and-Play Search with React + Vite

Charpie — Fri, 30 May 2025 19:14:24 +0000

Vite fam, we just launched a new open-source Vite + React template that makes it easy to integrate search into any web app using Searchcraft, our Rust-powered, developer-first search engine built for frontend teams.

If you’ve ever struggled with search integrations that feel like setting up a data center, this is for you.

Use the template via GitHub or degit from the command line: npx degit searchcraft-inc/vite-react-searchcraft-template <app_name>
Sign up at Searchcraft.io (free)
Plug in your API key and start building!

We’d love your feedback: PRs, issues, and stars welcome!

What happens when a designer builds a developer tool?

Charpie — Mon, 26 May 2025 18:20:07 +0000

I never set out to build a developer tool, let alone a search engine platform. My background is in design and product, not writing low-level code. Yet here I am, a designer who co-founded a developer tool company. The journey didn't start at any specific time but rather became a passion over years of behing exhausted by the same tools with the same annoyances void of inspiration or delight. The choice always seemed to be between wrestling with an ok open-source tool that either does half the things you want or required deep specialized expertise, or hand our fate to a SaaS tool with eye-watering costs. Along the way, I felt the misalignment between who builds search tools and who uses them. The people who created the legacy search systems weren't the ones in the trenches trying to integrate search into a live product on a tight deadline. I was convinced there had to be a better way.

Push and Pull

Coming from a design background, I approached building our developer tool, Searchcraft, differently. Instead of assuming users would bend to the tool, we designed the tool around the users (the developers, product managers, and even content teams who rely on search). This design-thinking approach meant focusing on clarity, reducing complexity, and creating a delightful experience in a domain usually known for concepts that fail to get abstacted effectively.

I've always loved the tension between designers and developers. That awkward, beautiful push and pull that happens when you try to turn an idea into something real. When you care about the how and the why equally.

It's not always easy. Sometimes it's frustrating as hell. But the outcomes are almost always better. Eyes light up at unexpected moments. You ship something neither side could have done alone.

That kind of collaboration changes your perspective. You start to notice where tools create distance instead of clarity. Where processes protect control but stifle creativity. Where the people with the ideas are cut off from making them real.

And you start to wonder: why does it have to be like this?

When Builders Aren't the Users

Traditional search infrastructure has long suffered from a disconnect. On one side, you have search engines like Elasticsearch or Solr, born from brilliant engineering but complex, requiring standing up clusters, managing devops, and constant tuning and reconfiguring via command lines. On the other side, you have newer SaaS services like Algolia that make search easier to adopt but often become prohibitively expensive at scale. In short, search has historically been an infrastructure headache that eats up engineering time and becomes a hidden drain on budget that's rarely accounted for. I felt this pain firsthand as a product designer trying to deliver good discovery experiences; the tools at my disposal were either too CLI-heavy and complex, or simplified to the point of opacity. Neither was ideal for a fast-moving product teams focused on user experience, ROI, or traction.

This misalignment exists because, traditionally, search tools were built by back-end search experts for back-end search experts. The everyday developers (and designers) who implement search were second-tier considerations. This has created powerful systems that often aren't designed with today's front-end developers, product owners, or the next generation of no-code builders in mind. I remember craving simplicity and clarity and fun, and I suspected that even veteran engineers were weary of the unnecessary complexity.

Breaking the Legacy Lock-In

One of our strategic goals with Searchcraft was to break the legacy lock-in of traditional search solutions. Search tools are a great example of what I've come to think of as "legacy lock-in by fear." They're powerful. No doubt. But they're also heavy, brittle, and weirdly sacred. Nobody loves using them. But everybody uses them. Why? Because they're safe. Because choosing the same tool as everyone else means nobody gets blamed.

Meanwhile, the people actually building things are stuck. They spend hours tuning something only to wait days to see if it worked. They jump through hoops to make small changes. They live in infrastructure when they want to live in ideas. And maybe they're not even developers. Maybe they're designers, marketers, or PMs who know exactly how information discovery should behave but are too restricted by legacy platforms and outdated processes to shape it.

That's the part that broke my brain. Not that the tools were hard-but that we just accepted that and moved on, which is a pattern we've been holding for two decades.

My team aimed to change that by building a solution so straightforward and powerful that switching off the old stack is a no-brainer. In doing so, we had to bridge the gap between performance and ease-of-use that legacy players never quite closed. Our ideal existance puts us somewhere between the power, performance, and enterprise toolset of Elasticsearch with the user experience and managed options of Algolia, all while being available as both a fully flexible on-prem solution or a cloud-based service. It's a daunting feet, but the current landscape begs for something refreshing and we aim to get there one bite at a time.

From Backend Plumbing to Engagement Engine

Perhaps the most exciting thing about approaching search from a design and product perspective is reimagining what search could be for a business. Historically, search was treated as backend plumbing - a necessary piece of infrastructure, but not something that directly drives strategy. Because we are a product team, we're taking a different view: search can be a core user engagement and monetization layer if you build it right. When a user searches on your app or site, that's a moment of intent - a moment you can either fulfill brilliantly or squander. We wanted to help teams make the most of those moments.

That's why we talk about breaking the mindset of search as just a cost center. In fact, we've seen how a well-designed search can turn into a revenue stream for our customers. A better search experience means users find more content (driving engagement), increases domain authority (better SEO), improves conversion rates, and opens the doors to serve relevant sponsored content or ads alongside results or even builds potential for an in-house retail media network (driving revenue). Search and content discovery is a core foundational pillar to any platform (alongside auth, analytics, security, and more) yet often remains an afterthought when it could really be a growth engine for the business. It's time to change that by redefining developer tools as business drivers and customer-facing experiences.

Who gets to build dev tools?

Reflecting on this journey, I realize it exemplifies a broader shift in our industry. Developer tools no longer have to come only from deep-in-the-weeds system engineers. Increasingly, unorthodox perspectives are reshaping the infrastructure layer. In our case, a designer helped build a search platform. Elsewhere, you see front-end developers rethinking cloud platforms, or product managers creating developer services. These "outsider" influences are in fact becoming superpowers. By stepping outside the old assumptions, we can create dev tools that are both powerful under the hood and delightful to use on the surface.

As a designer-founder, I've learned that developers appreciate good design more than our industry often gives them credit for. The senior engineers and architects I speak with don't want fluff - they'll see through marketing hype in a second. But they do want tools that make their lives easier without compromising on capabilities. They want scalability, reliability, and ROI, packaged in a developer experience that isn't a pain. Delivering that requires collaboration between great engineering and great design. It requires asking basic questions like "why does it have to be so hard?" and having the audacity to answer, "Maybe it doesn't."

I believe the future of dev tools will be defined by this kind of cross-pollination. The next generation of infrastructure products will come from diverse voices who challenge the status quo. And that's good news for all of us. It means tools that are more accessible without losing power. It means faster integration, fewer headaches, more transparency. In the end, it means developers can spend more time building the unique features that matter to their users, and less time wrangling plumbing. That's the vision that keeps me excited: a world where even the lowliest infrastructure can be elevated by design and fresh thinking into something that feels high-level and human-centric. If Searchcraft is any indication, when a designer (or any non-traditional thinker) builds a developer tool, you just might get a product that surprises everyone - not by being flashy or hyped, but by working so effortlessly that it changes what you expect from the tools you use. And in my mind, that's the highest compliment a dev tool can earn.