DEV Community: Licto

Made with Wasp: how Searchcraft built a full-stack SaaS around their Rust search engine

Licto — Tue, 28 Jul 2026 08:29:47 +0000

TL;DR

Searchcraft is a search engine written in Rust: an Algolia / Elasticsearch alternative that's light enough to run full-text search over all of English Wikipedia on a single Raspberry Pi.
Their full-stack customer dashboard (auth, billing, analytics, index management) is built with Wasp and the Open SaaS template.
They could have built the SaaS layer themselves, but chose not to, so their engineering time stays in the Rust engine where they actually compete.
Wasp compiles to standard React + Node.js + Prisma, deployed on their own AWS and CI/CD. No lock-in, no restructuring.

What is Searchcraft?

Searchcraft is a search engine written in Rust, built for product search, site search, and content discovery, competing with Elasticsearch, Algolia, OpenSearch, and Solr on a simple bet: search should be fast to integrate, light on resources, and easy to run.

How light on resources? Their CTO, Don, runs full-text search over the entire English Wikipedia on a single Raspberry Pi. That's the engine's whole personality in one image: it doesn't need a cluster to be useful.

The team is small and bootstrapped: a handful of engineers who spent years running a dev agency before going all-in on their own product. That history matters here, because they shipped client work in Next.js, Nuxt, and Angular, whatever stack the client brought.

And they're in production. Their first customer is a publisher running 22 local news sites with around 4 million active readers, rolling out site by site, with e-commerce and B2B SaaS next in line. Searchcraft ships as a managed cloud service or self-hosted, with SDKs for JavaScript, TypeScript, and PHP.

Every engine needs a chassis - so they chose Wasp

The onboarding screen - Searchcraft's design is super cool!

Searchcraft's plan is developer-led growth: a developer who finds it at 2am has to get from curiosity to a working search box on their own. That means sign-up, orgs, roles, indexes, API keys, analytics, billing. A full, production-ready SaaS application (auth, database, background jobs, emails, payments, admin) wrapped around the thing you actually sell.

They could have built it, but chose not to. The SaaS layer is a hundred solved problems that still take months to solve again and then ask for maintenance forever, and every hour on auth flows and CRUD plumbing is an hour not spent on relevance ranking, ingestion speed, or memory footprint, the things Searchcraft actually competes on.

The answer came from inside the house: Don, the CTO, had been following Wasp. Open SaaS, Wasp's open-source template, meant auth, payments, and an admin panel existed on day one, as code they own, not services they rent. And they evaluated it like engineers: everything Wasp generates is standard React, Node.js, and Prisma they could read, trust, and run themselves, no magic to open up. It's their code, and it compiles to one integrated stack built to keep holding together as the app grows.

What they built: the full-stack customer dashboard

The dashboard is Searchcraft's control room, "a product within a product," where customers run everything from document ingestion to search tuning, team management, and analytics.

Three moments show what's actually running under the UI, because the dashboard isn't a static admin panel, it's a full-stack app where Wasp is doing real work end to end:

What's behind this screen: server-side queries turning raw search events into live stats and multi-tenant access control, all in one Wasp codebase.

What's behind this screen: a multi-tenant index registry in Prisma, kept in sync with the Rust engine over one API, with search events rolled up into the time windows above. The chart is React; the plumbing is Wasp's type-safe operations.

What's behind this screen: subscription plans and upgrades, the billing machinery every SaaS needs and nobody wants to hand-roll, running in the same Wasp app and wired into the quotas from the first screen.

Around those three screens sits the rest of a real SaaS: an ingestion pipeline that infers the schema as it pulls documents in, crew management with roles, access keys as managed secrets, and a code-snippets page that takes a frontend dev from API key to working search box in minutes. Multi-tenant, role-based, revenue-carrying, and it looks the part. For a search company, the user portal is the brand.

How it runs: Wasp next to Rust

The shape is the interesting part. On one side, the Searchcraft engine and its supporting services (provisioning, ingestion), all Rust, all theirs. On the other, the customer dashboard: a Wasp app (React + Node.js + Prisma) that talks to the engine over an API. Customer apps consume search through the SDKs and never know the portal exists.

Here's the architecture, drawn by the Searchcraft team:

The dashboard, a Wasp app, handles users, configuration, and analytics; the Searchcraft engine and its Rust services do the search. One API connects them, and customer apps reach search through the SDKs.

Two systems, one product, one API between them.

Wasp didn't ask them to restructure anything; it slotted in next to the architecture they already had. If your real product lives in Rust, Go, Python, or Java, this is the part that applies to you.

Deployment, their way. Wasp comes with one-line deployment commands for popular hosts, but teams keep full freedom over where the app runs. Searchcraft already had infrastructure on AWS, so that's where it went: their own CI/CD on Bitbucket Pipelines, client and server deploying separately onto the setup they already trust. Because a Wasp app compiles to portable artifacts, both doors stay open, and having that choice was part of the point.

What's next

Searchcraft is expanding the platform: Searchcraft Cloud, a self-hosted Core for teams running their own infrastructure, more SDKs, and AI-powered Search Result Summaries, with more coming for LLM-native search:

"We are building in MCP support so that you can connect it to an LLM if you want."

Search that agents can talk to, from an engine small enough to run anywhere: it's a good bet, and they get to make it because their engineering time goes into the engine, not the app around it. That was the whole trade: the hard problems stay in Rust, where their edge is, and the SaaS layer lives in a Wasp app they fully own.

If you're in the same spot (a real product in a custom backend, and you need a full-stack dashboard around it), that's the conversation Wasp wants to have with you.

Thanks to the Searchcraft team for the walkthroughs, the diagram, and the stories. Check out Searchcraft!

From 10 Failed Stacks to Production: How a Data Scientist Built a Job Board with Wasp, a Full-stack Framework for the Agentic Era

Licto — Tue, 21 Apr 2026 10:06:13 +0000

NOTE: Hireveld is currently down while Marcel works on a major refactor - but it's real, we swear! It'll be back up soon.

Marcel Coetzee is a data scientist and AI consultant based in South Africa. With a background in actuarial science and data science, he runs his own consultancy. He also builds SaaS products on the side. His latest project, Hireveld, is a job board tackling South Africa's broken hiring market. He built it entirely with Wasp after trying nearly every other stack out there.

Tell us about yourself. How did you end up building web apps as a Python developer?

My path has been a bit unconventional. I started in actuarial science, which involves insurance, mathematical statistics and risk modeling. From there I moved into data science, then data engineering, and eventually into building products. Python has been my main language through all of that.

Today I run my own consultancy doing data engineering and AI work. But I've always wanted to build my own things too, so I started learning the JavaScript ecosystem and working on SaaS products on the side. I'm not a JS native by any means, but with the rise of agentic coding tools, I realized I could finally turn my ideas into real full-stack applications without spending years mastering every corner of Node and React.

What's Hireveld, and what problem are you solving?

Hireveld's landing page - hire without the markup

Hiring in South Africa is expensive and opaque. Recruitment agencies take a massive cut of annual salary. The established job boards charge thousands of rands just to post a single listing. And too many roles still get filled through personal connections rather than merit.

I built Hireveld to change that. Employers post for free, applicants get ranked anonymously, and employers pay a flat fee to reveal candidates. It's simple, it's cheap, and it puts merit first. The whole thing runs on Wasp - auth, background jobs for expiring old listings, transactional email, payment integration, the works.

You mentioned trying about 10 different stacks before landing on Wasp. What happened?

Yeah, I went through quite the journey. I started with PocketBase because I liked the idea of owning my code and not being locked into a cloud platform. It's a solid tool, but I quickly realized I needed PostgreSQL for search, background jobs, and a frontend that wasn't stitched together by hand. It just didn't scale to what I was building.

Then I tried Next.js, Nuxt, Svelte - they're decent, but those codebases can grow extremely quickly. As someone who's still relatively new to the JS ecosystem, I'd hit the limits of my knowledge fast. I even tried Django, thinking I'd stick with Python, but it's accumulated so much over the years. Too much magic, too much stuff.

My philosophy is: the projects that succeed expose as few abstractions as possible to the user. I try to keep myself at the highest level of abstraction I can. When I found Wasp on GitHub, the config file clicked for me immediately. You declare what you want - auth, database, jobs, email - and it all works together. I was writing actual product code on day one instead of gluing infrastructure together.

Don't prioritize the important over the urgent. With other stacks I was spending time on infrastructure decisions that felt important but weren't getting me closer to a product. Wasp let me focus on the urgent thing: shipping.

You're a big advocate for agentic coding. How does Wasp fit into that workflow?

This is where Wasp really shines, and honestly I think more people need to know about it. I've been building Hireveld almost entirely through agentic coding - Claude Code in the terminal - and after trying 10 different things, Wasp is by far the best experience for AI-assisted development.

Here's why: context is the precious commodity. Every line of code in your project takes a chunk of the model's context window. Wasp keeps the codebase tight and small.

The .wasp config file means the AI can understand your entire app's architecture at a glance - your routes, your auth setup, your jobs, your entities. Instead of the agent crawling through hundreds of files trying to figure out how things connect, it's all declared in one place. And because Wasp is opinionated and constrained, the agent doesn't try to do 50 different things. When something is wrong, the compiler screams. That tight feedback loop is exactly what agentic coding needs.

Wasp respects the model's context length. It keeps things tidy. The constraint is the feature - it's what keeps both you and the AI from spiraling into a 20,000-line mess.

I should say - I'm not blindly vibe coding. I know where my files are, I know my routes, I hand-edit the main.wasp file when I need to. I take testing seriously, both e2e and unit tests. QA is the layer where you, the human, decide what you actually want to build. But Wasp gives me the structure to stay at a high level and be productive, even as someone whose main language is Python. Also bring my data science background to bear by simulating data to gauge how the system would react to real traffic.

You also contributed back to Wasp - tell us about the Microsoft Auth integration.

Hireveld's job search interface

Hireveld targets the South African enterprise market, and enterprises run on Microsoft. They need Entra ID (Azure AD) for single sign-on - it's non-negotiable. When I started building, Wasp didn't have a Microsoft OAuth provider. With most frameworks, that would mean either paying a fortune for a third-party service or building a fragile custom integration that becomes tech debt.

But Wasp's codebase is approachable enough that I could build the provider myself and contribute it back. The PR process was great - Carlos and the team were welcoming and helpful. That's the sweet spot I was looking for: a framework that's batteries-included enough that I'm not rebuilding auth from scratch, but open enough that when I need something custom, I can add it without fighting the framework.

The community in general has been one of the best parts. The developers are genuinely friendly, my contributions felt valued, and I can tell the team takes agentic coding seriously - they maintain a Claude Code skill, they keep their prompts updated, they engage with the tooling ecosystem. That's an unusual level of involvement for a framework team.

What would you say to a developer considering Wasp for their next project?

If you're building a full-stack web app in 2026 and you're using AI tools to code - which you should be - try Wasp. Seriously. I went through PocketBase, Next.js, Nuxt, Svelte, Django, and more. Wasp is the only one where I felt like I was building my product from day one instead of fighting my tools.

It gave me auth, type-safe full-stack operations, background jobs, and transactional email - all wired together from a single config file. Everything else - the ranking algorithm, payments, file storage - I built on top of what Wasp provided. That separation is what made it possible to ship as a solo developer.

And if you're coming from Python or another ecosystem and you're intimidated by the JavaScript world - don't be. Wasp abstracts away enough of the complexity that you can stay at a high level and be productive. I'm proof of that.

Wasp is the full-stack framework for the agentic era. It's the one that lets you focus on what you're building, not how you're building it.

Marcel Coetzee is a data scientist, AI consultant, and SaaS builder based in South Africa. You can find him on GitHub and reach out to him on coetzee.marcel2@gmail.com