When I started building Skedoff, I thought I was making a lightweight social media scheduler.
Turns out, I was actually building something much narrower — and much more intentional.
Not another SaaS dashboard.
Not another auto-posting tool.
Not another “connect all your accounts” platform.
What I really wanted was a local-first boundary between writing and publishing.
That difference ended up shaping the entire product.
The problem I had with existing schedulers
Most social media scheduling tools assume the same workflow:
- create an account
- connect your social platforms
- store drafts in the cloud
- pay monthly
- automate publishing
That model makes sense for:
- agencies
- marketing teams
- content operations
- people managing multiple clients
But I’m not building for that first.
I wanted something for:
- solo creators
- indie builders
- freelancers
- small businesses
- people who still want manual control
I didn’t want unfinished drafts sitting on someone else’s server.
And I didn’t want “productivity” to automatically mean “automation.”
What Skedoff actually is
Skedoff is a privacy-first, offline-first social media content planner.
It does not:
- require an account
- sync to a backend
- connect to social APIs
- auto-post
- collect analytics
Instead, it gives you a simple local workflow:
Draft → Queue → Published
That’s it.
You write posts offline.
You tag the intended platform.
You move them through a small workflow.
Then when you’re ready, you manually open the real platform and publish.
This is intentionally less “powerful” than a traditional scheduler.
That’s the point.
Why I intentionally avoided auto-posting
From a product perspective, auto-posting is tempting.
It sounds like the obvious “upgrade.”
But it comes with tradeoffs:
- platform integrations
- auth complexity
- token storage
- backend requirements
- API policy changes
- reliability issues
- more user trust required
- more surface area for bugs
And more importantly, it changes the product philosophy.
The moment the tool becomes responsible for publishing, it stops being a planning space and starts becoming infrastructure.
I didn’t want that.
I wanted the app to stay focused on:
- preparation
- intentionality
- low friction
- privacy
- control
For this product, manual posting is not a missing feature.
It’s a design choice.
Offline-first wasn’t just a technical choice
“Offline-first” is often described as an implementation detail.
In Skedoff, it’s also a product stance.
I wanted the app to feel like it belongs to the device, not to a service.
That means:
- it works without internet
- the core experience is always available
- no server dependency
- no “sign in to continue”
- drafts stay local by default
That’s especially important for content planning.
Publishing is online.
Planning doesn’t always need to be.
Current architecture choices
Skedoff is intentionally simple right now.
The current direction is:
- Flutter for cross-platform development
- local-first storage instead of cloud sync
- three-tab workflow for Draft / Queue / Published
- platform tagging without external integrations
- minimal navigation complexity
- manual publish flow instead of API-based automation
A lot of the challenge here isn’t adding more code.
It’s resisting code that pushes the app away from its core promise.
Why the UX is deliberately small
A lot of productivity tools become noisy because they try to solve every adjacent problem.
I wanted Skedoff to avoid that.
So instead of a big navigation structure, I kept it intentionally narrow:
- Draft → ideas and raw captions
- Queue → content you’ve decided is ready soon
- Published → a local record of what went out
That’s enough structure to be useful, but not enough complexity to become another management system.
The more I built it, the more I realized:
I wasn’t building a scheduler.
I was building a pause button.
Current status: submitted to Google Play
Right now, Skedoff is in the most awkward indie stage:
technically done, emotionally not fully convinced.
Current status:
- UI done
- local database done
- core workflow working
- platform tagging working
- search/filtering working
- Android build prepared
And the app is now submitted to Google Play for review.
If everything goes smoothly, I’m expecting roughly 3–5 days before it goes live, which seems normal for a first release (assuming review goes smoothly).
That phase is always weird.
There’s a gap between:
- “the app works”
- and
- “I’m ready to let strangers use it”
I’m in that gap right now.
What comes next
I’m trying to keep v1 intentionally narrow.
Next things I’m considering:
- local notification reminders for queued posts
- bulk actions
- export / backup improvements
- small workflow refinements
- possibly optional, privacy-respecting crash reporting later
The hard part isn’t deciding what to add.
The hard part is deciding what not to add.
Because I don’t want Skedoff to slowly become the exact kind of tool I originally didn’t want to use.
Product page and original write-up
If you want the full founder/story version, I published the original article on my blog:
- Original post: Building Skedoff: I Thought I Was Making a Scheduler, but I Was Really Building a Boundary
And the product page is here:
I’m Cahyanudien Aziz Saputra, building under FlagoDNA.
If you’ve built something similar — or intentionally avoided “obvious” features to protect a product’s philosophy — I’d love to hear how you handled that tradeoff.
Top comments (0)