Five Months In: What It's Actually Taken to Build Luuk

Every "behind the build" post runs the risk of becoming a highlight reel — the clean version of a story that was never clean while it was happening. We're writing this one differently on purpose. Luuk has been in active build for five months now, and the honest version of that timeline has more false starts, personnel gaps, and reopened tickets than it has milestones. That's the version worth writing down.

Why this one, and why us

Codecraft Developers didn't come to Luuk as an outside vendor picking up a spec. The founding insight — that Nigerian commerce runs on a trust ritual (talk first, agree on a price, verify each other, then commit) that never got translated into software — came from inside our own walls. That changes how you build. There's no client to hand a finished feature to and move on; the team that writes the code is the team that has to live with what happens when it's wrong.

Five months in, that's been both the hardest part and the reason it's still moving forward.

Building the team while building the product

We didn't start with a team built for this. We started with a small core and a conviction, and had to figure out — in parallel with writing actual code — who this product actually needed: engineers who could hold escrow logic and payment state correctly under failure, and just as importantly, people who understood that a "trust score" isn't a UX detail, it's the entire product.

Today, the core team building the app stands at just four people.

That search wasn't clean. We brought people in who were strong engineers but didn't have the patience for a product where the cost of a bug isn't a bad review — it's a real Nigerian buyer or seller losing real money mid-transaction. We had to let some of that go. We also found people who weren't the most senior on paper but understood the why immediately, and those hires ended up mattering more than the résumés suggested they would. Operating with a tight team of four has meant that everyone has to take direct ownership of complex, overlapping systems, leaving very little room for miscommunication.

The bugs that actually kept us up

We're not going to walk through our escrow logic or scoring mechanics here — some of this is genuinely how the platform stays safe, and publishing it would just be a gift to anyone trying to game it. What we can talk about honestly is the shape of what broke.

The hardest class of bug wasn't a crash or a bad query. It was state — two people acting on the same negotiation at nearly the same moment, a call verification completing a half-second after a payment state had already moved on without it, a video upload succeeding on the client side while the record it depended on failed silently on ours. None of these are exotic engineering problems. They're the ordinary cost of building something where two humans are making a real-time commitment to each other through your app, and your software has to referee that honestly, every time, including the 1-in-500 case.

For us, this challenge became highly visible during our early testing and initial rollout phases, when the server and database capacity broke down nine separate times. The system simply wasn't prepared to handle the concurrent load of users trying to negotiate and verify transactions simultaneously. Each bottleneck forced us to go back to the architecture, restructure how we queue requests, and figure out how to keep the application stable when traffic spikes.

Influencers, ambassadors, and the mismatch nobody warns you about

Growth work on Luuk ran into a problem that's specific to a trust-first product: most of the standard influencer/ambassador playbook is built for products where the goal is attention, and ours is the opposite — the goal is credibility. A launch post from someone with a big following gets you views. It doesn't get you a Nigerian seller who's been burned before to trust that this app is different from the last five.

We are still actively partnering with influencers and ambassadors, but the onboarding process has required a lot of trial and error. We ended up caring less about follower counts and more about whether a person's own audience already trusted them the way Luuk was trying to get strangers to trust each other. That's a slower, harder filter to build a program around, and it has meant saying no to some partnerships that would have looked good on a slide while we continue to search for the right fits.

Where we are now

At the five-month mark, the core escrow, negotiation, and verification features are live, but the platform is still very much in a stabilization phase. Having resolved the initial round of capacity breakdowns, our focus for the next month is strictly on infrastructure monitoring, database optimization, and carefully managing user concurrency to prevent future server instability. At the same time, we are slowly rolling out our ambassador partnerships to test how the system handles steady, organic growth.

None of this is a story about a smooth five months. It's a story about a product where the stakes for getting it wrong are a stranger's money and a stranger's trust, built by a team that was still figuring out who it was while it built it. We'll write the next one of these when there's more to say — including, if it happens, the parts that didn't work.

---

*This is a Codecraft Developers "Behind the Build" post — case studies and post-mortems from real projects, published with the involved team's permission.*