About Appointment Adder

Our Mission

We built Appointment Adder because health care appointment coordination shouldn't be this hard. Patient portals that won't export to calendars, manually typing appointment details from screenshots, coordinating multiple family members' appointments—these frustrations are universal, yet most solutions compromise your privacy by monetizing your health data.

We're building toward a better way: health care tools that process your data on your device, not in corporate clouds. While our current web app requires cloud processing (an honest v1.0 limitation), we're architecting for a privacy-first future where your appointment information never leaves your device unless you choose to share it.

Our Privacy-First Approach

Most health care apps collect your data, store it in the cloud, and analyze it on their servers. They promise security while reserving the right to use your data for "service improvement" or sharing with "trusted partners."

We're doing it differently. Appointment Adder is built on a fundamental architectural choice: your health information processes on your device, not in our cloud. This makes our product harder to build and less profitable in the short term. We're doing it anyway because the current approach to health care data is fundamentally broken.

Learn more about our privacy philosophy in Privacy-First Health Care: Why Your Data Should Stay On Your Device

Product Roadmap

We're transparent about where we're headed. This roadmap shows what we're building and why.

Phase 1: Web Platform (Current) - Honest About Limitations

Current architecture: Our web application stores appointment data in Firebase Firestore (Google Cloud infrastructure) for authenticated users. This cloud storage enables cross-device access to your appointments, account management, and usage tracking for fair rate limiting.

Privacy protections we do implement: Strong access controls (only you can see your appointments), no data monetization or third-party sharing, GDPR compliance with full export and deletion rights, encryption in transit and at rest, and data minimization (we only store what you explicitly save).

Why we started here: The web is accessible to everyone with a browser—no app download required. But browsers don't yet support the on-device AI capabilities needed for complex text extraction. Google's Gemini AI requires server-side processing, which means your screenshots pass through our Firebase infrastructure temporarily during extraction.

What we're honest about: This v1.0 architecture requires trust in our infrastructure and Google's cloud security. Your data passes through our servers during AI processing, and appointment details are stored in Firestore (though never sold or shared). This isn't our privacy-first vision—it's a pragmatic starting point that validates the product's value while we build toward true on-device processing.

For maximum privacy now: We also offer encrypted local browser storage for users who don't want cloud sync. This sacrifices cross-device access but keeps everything on your device.

Phase 2: Browser Extensions

Browser extensions will bring Appointment Adder into your email and patient portal workflows. One-click extraction from Gmail and Outlook, inline processing without leaving your portal, automatic calendar export—all where you already work.

Phase 3: iOS App

The iOS app is where our privacy-first vision fully manifests. Native on-device AI using Core ML and Apple's Neural Engine. Share sheet integration for processing appointments from any app. Everything happens locally—the screenshot never leaves your phone, and appointment details never touch our servers. Pure privacy.

Phase 4: Android App

Android brings privacy-first processing to the other half of the smartphone world using TensorFlow Lite and ML Kit. Background processing, flexible sharing, home screen widgets—all with complete local processing.

Phased 5+: Advanced Features

Beyond core platforms, we'll expand with:

• Family coordination: Separate profiles, role-based access, shared calendars with individual privacy
• Provider intelligence: Location services, typical appointment durations, preparation requirements
• Smart scheduling: Conflict detection, optimal appointment timing, travel time predictions
• Enhanced extraction: More languages, international formats, voice notes, complex documents

Our Technical Journey

Moving from cloud to on-device processing isn't just flipping a switch. It requires fundamental architectural changes and overcoming significant technical challenges.

Phase 1: Cloud-Dependent Web App (Current Reality)

Current architecture: User uploads screenshot → Firebase servers receive it → Google AI processes extraction → Results sent back → Appointments stored in Firestore (for authenticated users) with user-specific access controls.

What actually happens: When you're signed in (including anonymous accounts), your appointments are stored in Firebase Firestore to enable features like cross-device sync, data recovery, and usage tracking. Screenshots are processed by Google's Gemini AI and are not retained after extraction. All data is encrypted in transit and at rest, with strict access controls ensuring only you can see your appointments.

Why we started here: The web was the pragmatic choice for launch. Universal accessibility, rapid iteration, lower barrier to entry. It validated that people actually want this tool. The trade-off is requiring cloud infrastructure and trust in our security practices, which isn't ideal but necessary for a v1.0 web platform.

Phase 2: Hybrid Mobile Apps

Planned architecture: Native iOS and Android apps with smart processing logic. Simple extractions process locally using on-device AI. Complex extractions can optionally fall back to cloud processing with user permission.

This phase transitions users toward on-device processing while maintaining support for edge cases.

Phase 3: Full On-Device Mobile Apps

Target architecture: Complete local processing using device AI chips. iOS uses Core ML with Neural Engine acceleration. Android uses TensorFlow Lite with ML Kit. Zero cloud dependency for core functionality.

This delivers our privacy-first vision completely: data never leaves your device, works offline always, no trust required in company infrastructure, verifiable privacy through airplane mode testing.

Data Storage: Current Reality vs. Future Vision

Current (Web v1.0)

• Appointments: Stored in Firebase Firestore (Google Cloud) for authenticated users
• AI Processing: Screenshots sent to Google Gemini API, processed server-side, results returned
• Sync: Cloud storage enables cross-device access
• Privacy: Strong access controls, no monetization, GDPR-compliant, but requires cloud trust

Future (Mobile v2.0+)

• Appointments: Stored only on your device, optionally backed up to your personal cloud (iCloud, Google Drive)
• AI Processing: Complete local processing using device neural engines (Core ML, TensorFlow Lite)
• Sync: Peer-to-peer or personal cloud only—never through our servers
• Privacy: Zero trust required—data never leaves your device, works in airplane mode

We're building in public and being honest about where we are versus where we're going. The current web app makes pragmatic compromises. The mobile apps will deliver our full privacy-first vision.

Our Guiding Principles

These principles guide every decision we make:

• Privacy first, always: Your health information never leaves your device unless you explicitly choose to share it
• Solve real problems: We build features that address actual pain points, not features that sound cool but don't help
• Work with existing tools: Enhance the calendars and tools you already use, don't replace your entire workflow
• Accessibility matters: Health Care coordination shouldn't require technical expertise
• No lock-in: Your data is yours. Export it anytime. Stop using Appointment Adder whenever you want

What We Won't Build

Understanding what we won't build is as important as knowing our roadmap:

• We won't become a full EHR replacement (we extract appointments, not manage complete records)
• We won't require cloud storage of your medical data
• We won't create a social network around health care
• We won't sell your data to third parties
• We won't pivot to unrelated features for revenue
• We won't add complexity that compromises usability
• We won't sacrifice privacy for convenience features

We stay focused on our core problem: making health care appointment coordination easier while respecting privacy.

Why Other Companies Don't Build This Way

If privacy-first architecture is so great, why don't more companies adopt it?

• It's genuinely harder: On-device AI requires more skilled engineers, more careful design, more testing across diverse devices
• It's less profitable: Health Care data has value. Privacy-first architecture deliberately eliminates data monetization revenue streams
• It's slower to improve: Cloud systems improve by analyzing billions of user interactions. On-device systems improve through manual model training and app updates
• It challenges industry norms: Investors expect data monetization. Partners want central databases. Going privacy-first means swimming against powerful currents
• Most users don't demand it: People don't prioritize privacy until they experience consequences of privacy violations

These are real obstacles. We're overcoming them because we believe the result justifies the difficulty.

How You Can Help

Want to support Appointment Adder's development?

• Use it: The more people using the tool, the faster we can expand and improve
• Share feedback: Tell us what works, what doesn't, what's missing
• Spread the word: Help others frustrated with appointment coordination
• Consider premium: Premium subscriptions fund development while maintaining free tier
• Report issues: Bug reports and feature requests directly improve the product
• Sponsor on GitHub: Support development directly via GitHub Sponsors

Realistic Timelines

The timelines in our roadmap are estimates, not promises. Software development rarely goes exactly as planned.

Current (Year 1): Web app with cloud processing. Continuous improvements to extraction accuracy, format support, UX enhancements. Honest about privacy limitations.

Near-term (Months 12-18): iOS app launch with hybrid processing (local for common cases, optional cloud for complex). Share sheet integration, Core ML implementation.

Mid-term (Months 18-30): Android app launch. Full on-device processing for both iOS and Android. Zero cloud dependency for core functionality. True privacy-first architecture achieved.

Long-term (Year 2+): Web app with WebAssembly on-device processing, continued accuracy improvements, cross-platform feature parity, family coordination features with privacy-preserving architecture.

We'll update our roadmap regularly as plans evolve. Development might accelerate with user growth or slow with unexpected technical challenges. Transparency matters more than hitting arbitrary dates.