We didn’t start on Sui.

‍

We came from backend engineering, dealing with real user load, production data, and systems that couldn’t afford surprises. We were already deep in EVM, Solana, and MultiversX. When we started building on Sui, we expected the usual learning curve. What we got instead was a full-on rewire of how we thought about state, logic, and scale.

This isn’t a general “Sui is different” article. It’s a breakdown of five moments that actually changed how we build.

‍

- These aren’t tips.

just things we would’ve paid to learn faster.

‍

‍

1. Don’t architect your contract like your backend

Our first attempt at modeling access control looked like our old NestJS API, global roles, user permissions, helper logic to route capabilities. It worked… until it didn’t.

On Sui, object ownership is the permission model. If your design fights that, you’ll constantly patch it with complexity. We ended up deleting half the glue code after embracing capability objects. The contract became simpler (and safer) by trusting the object graph instead of layering logic on top.

‍

‍

2. Move won’t let you lie to yourself

We once tried to burn an object created by another module. The compiler snapped. Then the runtime failed. It was brutal, and correct.

Move catches stuff you’d normally miss, ownership collisions, drop semantics, missing validations. It’s not just about safety, it’s about alignment. Once you get that, you stop trying to “work around” it and start using it.

‍

‍

3. Reading is harder than writing, and more important

We once shipped a drop flow that minted beautifully… but had no way to reliably track claims in real time. We built the UI off RPC calls, hit rate limits, and had no visibility into who actually owned what.

RPC endpoints weren’t enough. Rate limits kicked in. Indexing fell apart. That led to our open-source events-indexer, but more than that, it changed our mindset.

‍

- Now we start every build by asking: how will this be read?

‍

If the answer isn’t crystal clear, we rethink the design.

‍

‍

4. Deployment feels more like DB schema than app code

The moment you publish a package to mainnet, it’s immutable. There’s no redeploy, no hotfix. The mindset shift is subtle but massive: you need to think in migrations.

Now, every serious contract we write includes:

• a burn path (in case we need to clean up)
• version markers inside objects
• fallback logic if a shared object changes type over time

‍

‍

5. Backend logic moved on-chainm and got better

We used to write refund logic in backend services. Now we put it on-chain. Not because we had to, but because we could. Move lets us encode atomic guarantees that used to take half a microservice to enforce.

Since switching, our support load dropped, monitoring got simpler, and users stopped asking “when will this update?” because the chain already did it.

‍

‍

Where we landed

We don’t think of ourselves as Sui developers. We’re builders who rewrote our backend instincts in Move, because the chain gave us tools we didn’t want to fight.

Now, when teams ask us for help building on Sui, we give them these five lessons first. Not because they’re flashy, but because this is where things usually break.

If you’re heading down that road, hit us up. We’ve already stepped on the landmines.

‍