Building a product on someone else's API

Notebud was my 2016 side project: OneNote as a planner, with tasks from your to-do manager written onto each day's page, and later two-way sync of tags and tasks. It ran on the OneNote API. The platform was the product's foundation and I didn't control any of it.

What the API did to me

• Moved sections get new IDs. Move a section in OneNote and, to the API, it's a different section. Anything you stored against the old ID is now pointing at nothing.
• "The server is too busy." Page sync broke often with error 10007: too busy, try again later. Your product inherits every outage and every throttle.
• Ordering. Pages come back sorted by last modified, not in the order the user sees them in their notebook. Rebuilding the user's structure is your job.
• Unknowns. Do IDs differ per user in shared notebooks? What about tags?

What the survey said

I put a survey behind the sign-up form after a conference talk, in November 2016. People loved the idea. The recurring wishes: get tasks from Outlook into OneNote, reminders that work on a phone, task dependencies, an end-of-day review of plan against reality.

And two warnings I should have weighed more:

My greatest frustration with OneNote is the sync (terrible) speed. If I was to add a new application or add-on to my workflow it'd need to not have a significant impact on syncing.

I don't like the two-way synchronization because you risk using a lot of time just keeping two places synchronized with each other.

The very thing I was building, two-way sync, rested on the platform's weakest part.

What I'd do differently

Before building a sync engine on someone else's API, list what the API can't do, and find out whether anyone will pay for what's left. Enthusiasm in a free survey is not a paid appetite.

Background: a productivity tool based on OneNote, OneNote API and PHP, and the planning system it automated, life planning and journaling with OneNote.