Background & Motivation: Gaining App Build Experience and Observing Existing Platforms
The primary motivation behind developing Pintio was to expand my portfolio and independently acquire mobile app design and iOS building experience from scratch. I approached the project with technical curiosity. During development, an opportunity to travel to Sydney provided context: exploring local eateries made me realize that integrating multi-language support and multi-currency tracking would make the app highly practical for international travel.
Observing existing platforms also shaped my thinking. Local Japanese services like Tabelog prioritize ad-paying businesses in their search rankings, creating noise for users looking for objective choices. On the other hand, Google Maps is incredibly feature-rich, but its density can overwhelm everyday users looking for simple logging. While apps exist to drop pins on a map, I found no service that recorded specific menus alongside itemized pricing. Though a missing service could imply a lack of market demand, I decided it was an opportunity to build a focused tracking app with a reduced feature set.
Core Value & Implementation: Enhanced Review Experiences and AI Interaction Experiments
Choosing to implement receipt parsing instead of basic location pinning serves a specific purpose: extracting line items ensures that when users review their history, they can recall specific dishes and pricing details. Additionally, I wanted to experiment with embedding AI mechanics into user workflows and observe how it impacts product architecture and layout design.
The core features are fully deployed and running in the production environment. Using GPT-4 Vision, the application automatically extracts the establishment name, ordered items, expenditures, and dates from receipt photos. The multi-currency conversion logic automatically pulls exchange rates from an external API once a day to process values using current rates. I also established a follow-based map feed to display friends' logs and integrated Mixpanel tracking code to prepare for post-launch behavioral data collection (full database analytics scaling remains a future milestone).
Product Pivots: Three Architectural Shifts During Development
Throughout the development cycle, I pivoted the product direction three times based on real-world constraints and testing outcomes.
1. Shifting Priority from B2B-First to Consumer-First
Initially, I designed Pintio as a platform for store owners, building a complete management dashboard using Next.js and deploying it to a live server environment. However, I soon realized a structural flaw: business owners have no incentive to register on a platform devoid of an active user base. Recognizing that consumer demand must precede merchant supply, I pivoted the primary focus to the consumer app. The mobile application and the administrative dashboard share the exact same underlying database architecture, ensuring complete synchronization on the backend. The dashboard remains preserved for rollout once the consumer base matures.
2. Moving from Curated Onboarding to User-Generated Content (UGC)
The original design restricted map visibility to officially registered stores. Feedback from early testers highlighted that users wanted the freedom to add their own favorite locations immediately. I restructured the system to support user-generated entries. To maintain data quality, I implemented an automated validation logic on the database backend: a user-submitted location only publishes globally once 20 unique users log a visit to that establishment. (While this programmatic mechanism is fully operational, growing the user group to meet this threshold is a current milestone).
3. Expanding from Café-Specific Tracking to All Food Categories
Pintio began as a café-only tracker. However, testing confirmed that users valued the core capability—tracking dining experiences and expenses—regardless of the establishment type. Because the database was built flexibly, I expanded the scope to support restaurants, bakeries, and bars without requiring complex migrations.
Targeted Interface Adjustments Based on Initial User Testing
I distributed TestFlight builds to a small group of initial testers, including my brother and close friends. Their direct usage behaviors and candid input informed several UI/UX adjustments.
Methodology: AI Pair Programming and Prompt-Driven Implementation
Over the 12-month timeline, my technical approach shifted entirely from traditional coding to AI-directed implementation. I wrote raw code only during a brief initial period to learn basic React Native layouts. For the bulk of the project, I relied on conversational AI (Claude) to establish the software architecture based on my Figma designs.
For UI adjustments and logic implementation, I directed the AI using natural language prompts (e.g., "increase the margin here," "shift this element to the right"). By utilizing the AI to generate and refactor the actual codebase, I drastically reduced implementation time. This workflow allowed me to focus entirely on product direction and experience design, ultimately shipping a fully functional iOS app to the App Store single-handedly.
Retrospective: Post-Launch Strategy and Validation
This solo development cycle provided critical lessons in product sequencing, recognizing the necessity of reducing initial user friction, and leveraging AI for rapid engineering execution. Taking full ownership of a product's backend architecture as a solo designer offered deep insights into technical execution constraints.
Currently, in the post-launch phase, I am evaluating our first core hypothesis: "If logging visits provides standalone utility, users will return organically." I am monitoring retention rates to validate this. If the utility of logging alone is insufficient to drive retention, the next step is to expand the social map layers, increasing the visibility of friends' activities to drive engagement. I look forward to bringing this end-to-end operational experience into collaborative team environments.