Short answer
RaftLabs revamped the Astro front end of Avarik Saga, an Indonesian Web3 J-RPG, with one engineer over about one to two months. The work fixed bugs inside game-connected systems, added CSS fallbacks and workarounds so shared user actions behaved the same across devices and browsers, and reworked UI and animations. It cleared the way for new parts of the project to release on schedule.
Engagement
The Avarik Saga engagement
- Client
- Avarik Saga, a Web3 game studio in Jakarta, Indonesia, with roughly 20 people
- Decision-maker
- The studio's tech lead. Deeply technical, and ran his own technical interviews before engaging us
- What it was
- The game-connected website for a J-RPG with NFT characters, built on Astro
- What we owned
- A fixed list of bugs and changes: game-system bug fixes, mobile responsiveness, cross-browser behaviour, UI, interaction, and animation work
- Team
- One RaftLabs software engineer, working inside the client's existing codebase
- Duration
- About one to two months
- Evidence
- Engineering account only. RaftLabs holds no analytics, budget record, or client quote for this engagement
Avarik Saga is a Japanese-style role-playing game with NFT characters, built in Jakarta. Indonesian press have described it as the first NFT game made in Indonesia, and it partnered with the esports team RRQ to reach local players. Its website was not a brochure. It carried game-connected systems, interactions, and animations that players used directly.
That website had fallen behind the product. Parts of it needed a revamp. Mobile layouts were not holding up. Bugs sat inside the game-related systems, and the same user actions behaved differently depending on the device and browser. Each of those problems cost the team time and cost them players. More importantly, they stood between the studio and its next releases. Left alone, the studio faced delayed launches and a product players had less reason to trust.
The studio's tech lead interviewed candidates himself. He picked a RaftLabs engineer who already knew Astro, the framework the site was built on, and handed over a fixed list of bugs and changes. About one to two months later the list was clear, and the new parts of the project shipped on schedule.
starting point
The brief
The goal was not a redesign for its own sake. The studio needed its web front end to stop blocking releases, and to behave the same way for every player, on every device.
- Parts of the site needed a revamp to match the current product
- Mobile layouts broke or behaved poorly on smaller screens
- Bugs lived inside game-connected systems, not just the page layer
- Shared user actions behaved differently across devices and browsers
- Upcoming releases depended on all of this being fixed first
- The revamped sections and the fix list were delivered in about one to two months
- Mobile behaviour was reworked across the site
- The game-system bugs were traced to their source and fixed
- CSS fallbacks and workarounds gave players consistent behaviour across browsers
- UI, interaction, and animation changes we proposed were built in
- New parts of the project released on time
The hard parts of a short engagement
- 01
Tracing bugs through game systems we didn't write
Some of the bugs weren't in the page layer at all. They sat inside the systems that ran the site's game features, in a codebase RaftLabs hadn't built. The quick option was to patch the symptom where it showed up on screen. That would have closed tickets and left the cause in place for the next release to trip over.
Our engineer read the relevant modules line by line until he understood how each game feature actually worked, then fixed the bug where it started. This was before AI coding tools were part of the workflow, so there was no shortcut. It was slow at the start and paid off on every fix after it, because each one built on a real understanding of the system.
- 02
Making shared user actions behave the same on every device
Players reached the site from many phones, tablets, and desktop browsers, and each handled the same user actions a little differently. Those actions weren't decoration. They were an integral part of the experience.
One option was to narrow the list of supported devices and browsers. We didn't take it, because it would have cut out real players. Instead we added standard, industry-grade workarounds for the known differences, plus backup handling for the cases where the primary path failed. The result was one consistent experience, regardless of how a player arrived.
- 03
CSS fallbacks instead of a supported-browser list
The layout and animation work had the same problem at the styling layer. Modern CSS features that looked right in one browser rendered badly, or not at all, in another. This is the decision the engineer is most proud of: layering CSS fallbacks and compatibility changes so the site adapts to most devices and browsers, rather than looking right in a few.
A fallback strategy takes longer to write than a single modern stylesheet. It is also the difference between a site that looks finished on the team's own laptops and one that holds up on the phones players actually own.
- 04
Proposing changes, not just clearing tickets
The scope was a fixed list, and the list got done. Along the way we suggested a set of UI, interaction, and animation changes where the existing behaviour made the experience worse than it needed to be. The studio agreed, and those changes shipped with the rest of the work.
We didn't uncover anything about the studio's business it didn't already know. What we did add was a sharper scope: a clearer breakdown of the work, so the tech lead could see exactly what was being fixed and in what order.
outcomes
What we achieved
The studio's own team was focused on the game and upcoming releases.
Mobile layouts, cross-browser behaviour, and game-system bugs were all open at once.
Without the fixes, the studio faced delayed launches and lower confidence in the product.
The lesson
Astro can carry a lot more than a marketing site
If you're a game or Web3 studio with a web front end that players actually use, the thing most teams miss is that the framework choice isn't what's holding you back. Astro has a reputation as a tool for fast marketing pages. Avarik Saga's site ran game-connected systems, interactions, and animations on it, and the framework handled that fine. The problems were the ordinary ones: bugs nobody had traced to their source, and behaviour tested on too few devices.
So before you plan a rewrite, check two things. Has anyone read the failing systems end to end, rather than patching what shows on screen? And has the site been tested on the phones and browsers your players actually use? A focused engagement on those two questions often costs less, and ships sooner, than moving to a new stack.
stack
What the stack was responsible for
- 01AstroThe studio's existing framework, and the reason they chose an engineer who already knew it. We kept it rather than proposing a rewrite: it was fast, it handled the game-connected features, and the problems were in the code on top of it, not in Astro itself.
- 02CSS fallbacks and compatibility layersProgressive fallbacks let modern layouts and animations degrade gracefully on browsers that don't support them, instead of breaking. We chose this over publishing a narrow supported-browser list, because the players were already on the devices they had.
- 03Cross-device interaction workaroundsStandard workarounds, plus backup handling, for the differences in how devices and browsers process the same user actions. They kept the core interactions consistent without forking the code per device.
Evidence and limitations
Reviewed 23 September 2026
- Source. Everything about the engagement on this page comes from the delivery engineer's written answers in Asana on 21 September 2026. He was the only RaftLabs person on the project.
- No outcome numbers appear on this page. The studio didn't share analytics with us, so we hold no before-and-after figures for traffic, load time, conversion, or player retention. The only outcome we can state is the one the engineer saw directly: the new parts of the project released on time.
- Duration is approximate. The engineer recalls about one to two months. We have no contract record to narrow that.
- The engagement model and budget are absent. The work ran against a fixed list of items. We hold no record of the commercial terms, so we haven't guessed them.
- The original pain in the client's own words, and anything they tried before us, are absent. Nobody at RaftLabs holds that history.
- There is no client quote on this page. The engineer's account is that the studio was satisfied with the work. We haven't turned that into a testimonial.
- What happened next. The engagement ended when the list was done. RaftLabs isn't currently working with Avarik Saga.
- Public facts about Avarik Saga (its genre, its NFT model, its RRQ partnership) come from the Indonesian press sources linked on this page, not from RaftLabs records.
- Client sign-off on this page has not been obtained.
Questions buyers ask about game and Web3 website work
One RaftLabs engineer worked inside Avarik Saga's existing Astro codebase for about one to two months. He fixed bugs in the site's game-connected systems, reworked mobile responsiveness, added CSS fallbacks and workarounds so shared user actions behaved consistently across devices and browsers, and built UI, interaction, and animation changes we proposed. The work cleared the way for new releases to ship on schedule.
Yes. Avarik Saga's site ran game-connected systems, interactive features, and animations on Astro, and the framework wasn't the constraint. The problems we fixed were untraced bugs and inconsistent behaviour across devices, which would have followed the site to any framework. Astro's speed makes it a reasonable choice for interactive, player-facing sites, provided the code on top of it is tested on real devices.
It depends on scope, not on the Web3 label. Avarik Saga's engagement ran against a fixed list of bugs and changes and took about one to two months with one engineer. A full redesign, new wallet or marketplace features, or smart-contract work would take longer. The fastest route is a clear, ordered list of what's broken before any work starts.
Start by testing on the devices players actually use, then fix at two layers. At the styling layer, add CSS fallbacks so modern layouts degrade gracefully instead of breaking. At the interaction layer, add standard workarounds and backup handling for how different browsers process the same user actions. Narrowing the supported-browser list is faster, and it cuts out real players.
Fix it in place first, unless the framework itself is the limit. On Avarik Saga the bugs came from game-system logic and cross-browser gaps, not from Astro, so a rewrite would have moved the same problems to a new codebase and delayed the release. Reading the failing systems end to end usually tells you within days whether a rewrite is justified.
The engineer's honest answer is not much. The work was scoped as a fixed list, nothing was cut to hit the date, and no shortcuts were taken. The one thing we'd add today is measurement: agree up front on a few numbers, such as mobile error rates or page load times, so the result can be shown in figures and not only as an on-time release.
Read our website development service, our web application development approach, and our game development industry page. This case study is the delivery evidence for a short, focused front-end engagement. Those pages explain how we scope larger builds.
Related work
