Today I simulated a server breach.
Question I ask myself:
If someone hacks the server today, what can they steal?
Answer should always be:
Encrypted data that cannot be decrypted.
#buildinpublic #indiedev
One challenge with zero-knowledge backup.
If user forgets password, data cannot be recovered.
No admin reset.
No backdoor.
Privacy always comes with responsibility.
#buildinpublic #indiedev
Architecture update for Safety Photo+Video backup.
Flow now looks like this:
Local file
→ encrypt
→ split to chunks
→ upload
→ verify hash
→ commit manifest
More complex but much safer.
#buildinpublic #indiedev
The hardest part is context switching between coding, debugging, and support. But support emails also remind me real users rely on the product — that keeps me going.
Chunk encryption lets me stream the video instead of loading it all into memory. Each chunk is encrypted and written immediately, keeping RAM stable even for ~4GB files. Still tuning chunk size vs CPU/battery trade-offs to find the sweet spot on mobile.
Discovered a bug in backup verification.
Hash was calculated before encryption instead of after.
Meaning corrupted encrypted files could pass verification.
Security bug fixed.
Small detail. Big consequence.
#buildinpublic #indiedev
Reality of indie dev life.
Morning: coding encryption module
Afternoon: debugging upload timeout
Night: replying support emails
Building a product alone is basically wearing 10 hats.
#buildinpublic #indiedev
Challenge of the day.
Large video files.
Encrypting 4GB videos on mobile devices stresses:
CPU
memory
battery
Trying chunk encryption to keep memory stable.
#buildinpublic #indiedev
The toughest part was balancing strong end-to-end encryption with reliable sync and migration. Since it’s zero-knowledge, the server can’t read or verify the data, so integrity checks have to happen client-side using hashes and encrypted metadata.
Design decision today.
Every photo and video must be encrypted on the device before upload.
Server only stores encrypted blobs.
Which means debugging becomes… interesting.
You cannot even see the real file.
#buildinpublic #indiedev
Starting this week rebuilding the cloud backup system for Safety Photo+Video.
Goal: zero-knowledge encrypted backup where even the server cannot see user data.
Sounds simple.
Actually one of the hardest systems I have built.
#buildinpublic #indiedev
Two weeks rebuilding the backup core.
No big launch post.
No hype thread.
Just steady improvements.
Sometimes the best upgrade is the one nobody notices — until the day they need it.
#buildinpublic #privacy #indiedev
Working alone has one advantage.
I can decide:
We do not log sensitive metadata.
No tracking what photos are.
No analyzing user files.
Just storage.
Privacy is not a feature.
It’s a principle.
Today’s invisible upgrade:
Added local encryption key rotation support.
Not for marketing.
Not for announcement.
Just future-proofing.
Indie dev mindset:
Build today like someone will attack you tomorrow.
Most cloud apps focus on growth.
I focus on:
• Data integrity
• Encryption validation
• Restore reliability
Because backup is meaningless if restore fails.
Spent today stress-testing restore logic.
I asked myself:
If someone hacks my server tomorrow, what do they get?
Answer:
Encrypted blobs.
No keys.
No metadata.
No thumbnails.
That’s the benchmark.
Still early and experimenting 😅
Tried: posting build updates on X, sharing short feature demos, tweaking landing page/SEO, and some light outreach.
I’m committing to:
30 days of building in public.
Even if nobody reads.
#buildingInPublic
Today’s struggle:
Balancing engineering vs marketing time.
Code feels productive.
Posting feels uncomfortable.
#buildInPublic
Small UX detail:
If encryption takes 1–2 seconds, users think the app is frozen.
So I added:
• Local processing indicator
• Real-time chunk progress
• Background safe retry
Security must feel smooth.
Building alone is underratedly hard.
No team.
No hype.
No validation loop.
Just you and the problem.
#buildInPublic
Today’s goal:
Reduce backup time without compromising encryption strength.
Optimization idea:
Parallel chunk uploads + local encryption queue.
Performance and privacy don’t have to fight.
They just need architecture.
Reflection:
Indie hacking isn’t about shipping fast.
It’s about shipping something you can sleep peacefully with.
Security is invisible.
But regret is not.
My long-term vision:
AI that understands your files better than you do.
Auto organize.
Auto summarize.
Fully private.
Rewrote part of sync logic.
Before:
Upload → Confirm → Mark success
Now:
Encrypt → Hash → Upload chunk → Verify integrity → Commit manifest
Feels slower to build.
Feels safer to ship.
As a solo founder, your biggest bottleneck is:
Energy.
Not ideas.
Not skills.
Mistake I made before:
Shipping silently.
Nobody knew what I was building.
Marketing starts BEFORE launch.
I’m thinking long term.
Not building to sell in 6 months.
Building infrastructure that can last 10 years.
Zero-knowledge architecture is painful.
If users forget password →
There is NO reset.
Because we don’t store keys.
Security has trade-offs.
Today I worked on:
– Account deletion flow
– Cloud migration logic
– Encryption verification edge cases
Shipping security features is stressful.
