Ideas to Action

I discovered a hackathon pitched as an opportunity to use AI for good. I thought it would be a good challenge to find out whether I could manage, design, build, test, release, and pitch a mobile app entirely by myself.

I had already experimented with using voice dictation for a journal and had also been interviewing pastors, parents, and teenagers to find out their biggest challenges with turning good intentions into action. So I created diakuō to turn transcribed prayer and Bible study into a journal of actions for measured growth.

• Role: Product, design and development
• Platform: iOS, Expo and TestFlight
• Timeline:
  v0.1.0 on Sep 30
  v0.6.0 on Oct 7 (hackathon demo)
  v0.7.0 on Oct 15 (post-hackathon)

Early Research

I asked 10 adults (parents and pastors) and 4 teenagers what their most difficult challenge is from their perspectives as Christians that they wish was easier. I recorded and transcribed some of the conversations and took notes from other informal discussions. Then I consolidated them into common themes:

• Pastors: Communicating with people in relatable and understandable ways.
• Parents: Help kids understand the Bible because the Bible is very complex.
• Teenagers: Figuring out how to navigate new situations for the first time.

Product Charter

Every product I work on has a product charter that provides a high-level overview of why the product exists, specific commitments that every release needs to align with, and a roadmap with purpose, goal, and features. After release, links are provided for the plan, decisions, and release notes.

Managing Context

Even small products have a lot of context to manage and that context can quickly muddy a roadmap or bloat an AGENTS.md/CLAUDE.md file.

I manage context across multiple linked files in a docs folder:

• Product Charter: Holds commitments and roadmap and is described above.
• Architecture: A reference for product structure, platform details, core technologies, and guiding decisions and principles.
• Roadmap: Contains proposed work noted in a plan document.
• Releases: Once roadmap work is completed, its folder is moved along with the plan, decisions, and release notes. Links to these documents are listed in the Product Charter.

Roadmap & Priorities

When working with teams, I've used tools such as Azure DevOps, Jira, or Miro. For this project I created a user story map on a whiteboard for concepts and provided a photo to Claude.

I then created a rough roadmap in my Product Charter and limited detailed planning to current work.

This allowed me to see the big picture without getting overwhelmed, focus on details where most beneficial, and adapt my plan based on feedback and discovery.

Expo

I had one week to build a fully functional mobile app. I had designed mobile apps before but never developed one, so I reduced complexity as much as I could to meet the deadline.

• Familiar: I'd already used TypeScript to build my portfolio site and another product.
• Fast: Development builds and over-the-air updates.
• Delivery: EAS handles builds and TestFlight submission.
• Open: Android stays possible later, and native modules are still reachable for on-device speech, SwiftUI menus, and YouVersion SDK.

If I decided to go fully native on iOS and Android after the deadline, I'd have a working app to reference and could compare functionality and responsiveness against it.

Docker Sandbox

I used Claude Code as a code and iteration partner but wanted to avoid granting root access to my machine.

I decided to set up a Docker Sandbox restricted to my project with granular control of outside web access and ability to inject credentials via Apple keychain to avoid plain text secrets.

This took me two days to research and set up, but helped me move faster with confidence and allowed me to start larger builds and shift focus to other areas.

Builds and Testing

I created Expo and Apple Developer accounts and then set up certificates and App Store Connect. My Apple Developer account was approved in about 8 hours, allowing me to release my v0.2.0 build to five testers.

I delivered each build through TestFlight while Expo's EAS Update enabled me to push instant over-the-air updates between full builds.

Information Architecture

The MVP design was fairly simple with only one level of interaction across a tab menu. However, once I started to add detail views and separate journaling as a more distinct workflow, I needed to visualize structures and related design patterns.

Normally I might use Figma, tables, and/or mindmaps for this work. For this project I decided to sketch on a whiteboard, provide a photo to Claude, and take more of a sculpting approach to design while building.

I gave Claude access to Apple's Human Interface Guidelines and was able to build around those standards and capabilities without needing a formal design handoff stage.

Expo vs. Native iOS: For my first mobile app, built alone in a week, Expo was a great choice. However, I had to work through challenges with…

• Liquid Glass theming
• Laggy animations and tab menus

I’d want to compare native iOS/Android with Expo to measure tradeoffs directly for the following reasons…

• I think AI makes managing two native codebases more feasible than in the past, with one less layer of framework and bug fixes between design and platform.
• Native components follow each platform's guidelines out of the box, and native work can adopt new features during developer previews.

Dev Environment: I'd set up the sandbox and my Apple Developer account first, so I could install on devices and test earlier. My first test release came on day 4, with several features already built.

Demo: Several teams had people who were focused on creating a presentation of what they were building. I needed to do both and was context switching a lot the last day between capturing video clips, testing final build, and creating the presentation. Moving forward, I'll begin drafting story and promotion as I start building so I can iterate both together.