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 moving toward a fundamental architectural choice: your health information will process 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), encryption in transit (HTTPS) and at rest (a Google Cloud default), and data minimization (we store what you save, the usage counts behind rate limits, and, if you turn on reminders, the email address and schedule needed to send them). Our usage analytics never include your appointment details.

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). Some features also send data to other services: Google Gemini reads what you upload, Google Cloud Vision reads the text in screenshots, Google's Model Armor checks extraction requests for abuse before Gemini sees them (if Model Armor is unavailable, a request still goes ahead unchecked), Google Maps looks up addresses, and Pingram delivers reminder emails. 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: If you use Appointment Adder without signing in, your saved appointments stay in your browser instead of our database. This sacrifices cross-device access, and anyone who can use that browser can see them, so clear them when you are done on a shared computer.

Phase 2: Mobile Apps

iOS and Android apps that read appointment confirmations on your phone. Share a screenshot or email from any app, and common confirmations are handled entirely on your device. A confirmation the phone can't handle is sent for cloud processing only if you allow it.

Phase 3: Fully On-Device

This is where our privacy-first vision fully arrives. Extraction and storage happen on your phone, the screenshot never leaves it, and appointment details never touch our servers. As browsers gain the on-device AI this needs, the web app will follow.

Phase 4+: Advanced Features

Beyond core platforms, we'll expand with:

• Family coordination: Separate profiles, role-based access, shared calendars with individual privacy
• Provider intelligence: Typical appointment durations for each provider
• Smart scheduling: Optimal appointment timing and travel time predictions
• Enhanced extraction: International formats and more 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. A guest (anonymous) account and everything it saved are deleted after 30 days without use. Screenshots are processed by Google's Gemini AI, with Google Cloud Vision reading their text and Model Armor screening requests when available. We don't save them, but how long Google keeps them follows Google's API terms. Data is encrypted in transit and, as a Google Cloud default, 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: 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: Fully On-Device

Target architecture: Complete local processing using the AI hardware built into your phone. Zero cloud dependency for core functionality.

This will deliver our privacy-first vision completely: data will never leave your device, the app will work offline always, no trust will be required in company infrastructure, and privacy will be verifiable 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, with Google Cloud Vision reading their text and Model Armor screening requests when available, processed server-side, results returned
• Sync: Cloud storage enables cross-device access
• Privacy: Strong access controls, but requires cloud trust

Future (Mobile Apps)

• Appointments: Stored on your device, with optional backup to cloud storage you choose
• AI Processing: Done on your phone
• Sync: Only through storage you choose—never through our servers
• Privacy: Zero trust required—data will never leave your device, and the app will work 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: We're working toward your health information staying on your device unless you explicitly choose to share it. The web app isn't there yet
• 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
• Report issues: Bug reports and feature requests directly improve the product
• Sponsor on GitHub: Support development directly via GitHub Sponsors

How We Plan

We don't publish dates. The roadmap above is an order, not a schedule: we build what comes next and say so when it ships. Our help articles announce each new feature as it arrives.