Introduction
The next billion mobile users aren't getting smartphones, they're getting $20 flip phones running KaiOS. While the tech world obsesses over the latest iPhone, over 200 million people worldwide rely on feature phones with limited capabilities but essential connectivity.
My challenge: Build BlueKai, a fully-featured BlueSky client for devices with 256MB RAM, Gecko 48 (Firefox from 2017), and D-pad navigation. No touch screen. No modern JavaScript APIs. Just the basics, and the determination to bring decentralized social networking to users in remote areas with limited data plans.
This is the story of how I used Kiro, an AI-powered IDE, and a spec-driven development approach to ship a production-ready app in days instead of weeks.
The KaiOS Challenge
KaiOS sits in a unique position in the mobile ecosystem. It powers affordable feature phones sold primarily in emerging markets across India, Africa, Southeast Asia, and Latin America. For many users, a KaiOS device represents their first (and sometimes only) connection to the internet.
But building for KaiOS means confronting constraints that modern web developers rarely encounter:
The Technical Constraints
- Ancient browser engine: Gecko 48 (equivalent to Firefox from 2017) means no Fetch API, limited ES6 support, no modern CSS features
- Tiny bundle budget: Target under 200KB gzipped for users on prepaid data plans where every kilobyte costs money
- D-pad only navigation: No touch screen. Everything must work with up/down/left/right arrow keys and a select button
- Resource constraints: 256MB RAM total, shared between the OS and all running apps
- Small displays: 240x320 pixel screens in portrait or 320x240 in landscape
- Global audience: Users speaking dozens of languages, including right-to-left scripts like Arabic
- Intermittent connectivity: 2G/3G networks with frequent drops and high latency
The Platform Reality
Unlike iOS or Android where you can find tutorials, Stack Overflow answers, and active communities, KaiOS development is niche. Documentation is sparse. The community is small but passionate (shoutout to BananaHackers). Most developers build once and move on.
This made it the perfect test case for AI-assisted development.
Enter Kiro: AI-Assisted Development
Traditional development for a platform like KaiOS is slow. You're constantly:
- Researching obscure browser limitations
- Finding workarounds for missing APIs
- Testing on actual hardware (emulators are unreliable)
- Debugging issues that modern DevTools don't handle well
Kiro's conversational approach proved invaluable. Instead of searching documentation or Stack Overflow, I could describe behaviors in natural language and get immediate, contextually-aware solutions.
Example: Early in development, I noticed strange scrolling behavior. I told Kiro: "The cursor can start on top of the action bar and prevent scrolling." Within seconds, Kiro identified the z-index issue and provided a fix that accounted for KaiOS's specific rendering quirks.
But Kiro's real power wasn't just answering questions. It was helping me think through the entire architecture before writing a single line of code.
The Spec-Driven Approach
I adopted a three-phase workflow that kept me from drowning in complexity:
Phase 1: Requirements
Before touching any code, I worked with Kiro to define comprehensive user stories using the EARS (Easy Approach to Requirements Syntax) format:
- WHEN the user logs in THEN the system SHALL authenticate using BlueSky ATP protocol
- WHEN authenticated THEN the system SHALL display the user's home timeline
- WHEN viewing the timeline THEN the system SHALL show posts with author, content, and timestamp
- WHEN the user selects a post THEN the system SHALL allow liking, reposting, and replying
- WHEN the user navigates to compose THEN the system SHALL allow creating new posts up to 300 characters
This forced me to think through edge cases upfront:
- What happens when the session expires mid-scroll?
- How do we handle authentication on slow 2G networks?
- What if the user closes the app mid-login?
- What limitations come from the ancient browser engine?
- What's a typical screen resolution?
Phase 2: Design
With requirements locked in, Kiro researched both BlueSky's AT Protocol API and Gecko 48's limitations. It generated:
- Component hierarchies showing how UI elements related to each other
- Data models defining the shape of BlueSky posts, profiles, and threads
- A shared reference document that became the single source of truth
This wasn't boilerplate. It was thoughtful architecture that accounted for KaiOS's constraints. For example, the state management design used an observable pattern compatible with Gecko 48 rather than modern tools.
Phase 3: Tasks
Kiro broke the implementation into 25 discrete tasks with sub-tasks:
-
Set up Preact
- Configure build for ES5 output (Gecko 48)
- Set up development server
- Add bundle size analysis
-
Implement XMLHttpRequest wrapper
- Create Fetch-like API using XHR
- Add timeout handling
- Implement request cancellation
-
Build authentication flow
- Create login form with D-pad navigation
- Integrate AT Protocol session management
- Implement session persistence
Each task referenced specific requirements and could be executed incrementally. I could work on one task, review it, commit, and move to the next while maintaining momentum without losing context.
The Most Impressive Generation: Internationalization
The internationalization system showcased Kiro's ability to handle complex, multi-faceted problems.
I simply asked: "We need to support multiple languages for a global KaiOS audience."
Kiro didn't just generate a basic i18n setup. It created a comprehensive system:
Automatic Language Detection
The system detects the device language from KaiOS system settings and extracts the language code (for example, 'en-US' becomes 'en').
Eight Languages with Real Translations
Not placeholders but actual translations for English, Spanish, French, Portuguese, Arabic, Hindi, Swahili, and Indonesian. Kiro researched appropriate terminology for each language, including technical terms like "timeline" and "repost."
RTL Support
The CSS automatically applies right-to-left (RTL) text direction and reversed flex layouts when Arabic is selected, ensuring proper display for RTL languages.
Graceful Fallbacks
The translation system checks the current language first, falls back to English if the key isn't found, and finally displays the key itself if no translation exists. This ensures the app never shows blank text.
This level of thoughtfulness (supporting RTL, providing real translations) would have taken days of research and implementation. Kiro delivered it in one session.
Hybrid Development Strategy
I discovered that different types of work benefit from different approaches:
Specs for Foundational Features
Complex, multi-component features like architecture, state management, and the AT Protocol API client benefited from the full spec-driven approach. These needed:
- Cross-session context preservation
- Systematic thinking about edge cases
- Comprehensive documentation for future maintenance
Vibe Coding for Iterations
Once the foundation was solid, I switched to conversational "vibe coding" for:
- Bug fixes ("The menu doesn't close when pressing Back")
- UI tweaks ("Make the timestamp smaller and gray")
- Performance optimization ("Can we lazy-load images in the timeline?")
This hybrid approach maximized both thoroughness and speed.
Technical Wins
Some solutions I'm particularly proud of:
XMLHttpRequest Wrapper
Since Gecko 48 lacks the Fetch API, I needed to wrap XMLHttpRequest in a Promise-based interface that provides modern async/await functionality while working within the browser's limitations.
Virtual Scrolling
With limited memory, rendering hundreds of posts would crash the app. Virtual scrolling renders only visible items plus a small buffer above and below the viewport, dramatically reducing memory usage.
D-Pad Navigation Manager
KaiOS navigation requires careful focus management. The navigation system listens for arrow key events and maintains a list of focusable elements, moving focus appropriately and triggering selection on Enter key press.
See the KaiOS D-pad navigation guidelines for more details.
Aggressive Caching
Users on prepaid plans can't afford to re-download content. Service Workers cache timeline posts, profiles, and media, responding with cached versions when available and only fetching from the network when necessary.
Bundle Optimization
Final bundle: 73.45KB gzipped, well under the 200KB target. Achieved through:
- Tree-shaking unused Preact features
- Dynamic imports for routes
- Optimized image loading
- Minification and compression
Learn more about optimizing apps for KaiOS.
Impact
BlueKai (bluekai.app) represents more than a technical achievement. It's about:
Bringing Modern Social Networking to New Markets
BlueSky's decentralized, ad-free approach is perfect for users on limited data plans. BlueKai makes it accessible to people who couldn't otherwise participate in the AT Protocol network.
Proving AI Can Tackle Niche Platforms
Most AI coding tools optimize for mainstream platforms (React, Next.js, iOS, Android). BlueKai shows that with the right approach, AI can handle obscure platforms with sparse documentation.
The Future of Global-First Development
If a solo developer can build a production-ready app for a niche platform in days, what becomes possible for small teams targeting underserved markets?
Conclusion
AI tools like Kiro make it feasible for small teams (or solo developers) to build for platforms that otherwise would have a steep learning curve with many paper cuts. The combination of spec-driven architecture and conversational iteration proved powerful: thoughtful design meets rapid execution.
BlueKai is open source and available at bluekai.app. Try it on any KaiOS device or in the KaiOS simulator. Built for Kiroween 2025.
Special thanks to the BananaHackers community and the KaiOS team for their documentation and tools.
Top comments (0)