DEV Community: Oleksandr

Your Side Project Doesn't Need a Security Team (But It Does Need a Checklist)

Oleksandr — Mon, 09 Nov 2026 04:26:56 +0000

I used to think that security was something only big enterprises needed to worry about. "Who's going to hack my little side project?" I'd tell myself. "I'm just building a simple SaaS for 10 users."

Then I saw a post on Reddit from a developer whose indie project got hit by a botnet. The attacker found a single unprotected API endpoint, exploited a simple IDOR (Insecure Direct Object Reference) vulnerability, and wiped his entire database.

That’s the thing about the internet: nobody cares how small you are. Automated scanners run 24/7, looking for open S3 buckets, exposed .env files, and missing authentication headers. If your app is public, you are a target.

I spent the next few weeks learning about web security. I didn't want to become a security expert — I just wanted to ensure my side projects weren't an easy target.

Here is the exact checklist I now use before deploying any side project to production.

Authentication & Authorization The most common bug in side projects is confusing authentication with authorization.

Authentication: Who are you?

Authorization: Are you allowed to see this?

I cannot tell you how many times I've seen an API endpoint like GET /api/user/123 where 123 is just the user ID. If you change 123 to 124, you can see another user's data. This is called IDOR.

The Fix: Never trust the client. If a user requests /api/invoices/123, your backend must verify that the authenticated user actually owns invoice 123. Use UUIDs instead of sequential IDs to make it harder for attackers to guess.

The .env File (The Silent Killer) As developers, we love open-source. But we often push our .env files to public GitHub repositories by accident. If your database credentials, API keys, or JWT secrets are exposed, your app is essentially a public frontend.

The Fix:

Add .env to your .gitignore file (do this immediately).

Use a tool like git-secrets or GitHub's secret scanning to prevent committing keys by accident.

Rotate your keys if you suspect they've been leaked. Don't just delete the commit — the data is already out there.

Rate Limiting (Why You Need It) If you have an API, you need rate limiting. Without it, a bot can brute-force your login page or spam your signup form, causing resource exhaustion or spamming your database.

The Fix: Use a middleware like express-rate-limit for Node.js, or use a service like Cloudflare or Upstash to rate limit requests at the edge. A simple rule like "100 requests per 15 minutes per IP" will stop 99% of automated abuse.

Password Hygiene If you're building an app, you're likely dealing with passwords. If you're storing passwords in plain text, stop what you're doing and fix it immediately.

The Fix: Use a strong hashing algorithm like bcrypt or argon2. Never write your own cryptography.

But the real security win comes from the user side. If you run any kind of SaaS, consider implementing 2FA (Two-Factor Authentication). It’s the single most effective way to prevent account takeovers.

I’ve actually built a Password Playbook that documents the exact steps for securing accounts in 30 minutes—it's great to share with your users or keep for yourself.

Never Trust User Input SQL Injection (SQLi) and Cross-Site Scripting (XSS) are still two of the most common vulnerabilities in web apps. If you're using an ORM like Prisma or Drizzle, most of these attacks are mitigated. But if you're writing raw SQL, you must use parameterized queries.

The Fix:

Sanitize and validate all incoming data using a library like zod or joi.

Use parameterized queries.

Set up a strict Content Security Policy (CSP) to prevent XSS.

The Pre-Deploy Checklist
Before you run npm run build and push to production, run through this checklist:

Authentication: Are all endpoints protected?

Authorization: Does every route verify ownership (IDOR)?

Input Validation: Is every request body validated with a schema?

Secrets: Is .env in .gitignore? Are there any hardcoded API keys?

Rate Limiting: Are your routes protected against spam?

Passwords: Are they hashed with bcrypt?

If you want the exact technical checklist I use for my own side projects, I’ve compiled it into an API Security Checklist. It walks through every endpoint, header, and token.

Stay safe out there.

Have you ever been hacked? What’s the biggest security mistake you’ve made in a side project? Let’s share our war stories in the comments!

The End of Boilerplate: How AI is Changing the Way We Build Side Projects

Oleksandr — Sat, 07 Nov 2026 04:29:14 +0000

Remember the "good old days" of starting a new side project?

You’d spend the first weekend just setting up the environment. You’d configure Webpack (or Vite), set up ESLint and Prettier, wire up a basic CI/CD pipeline, configure the ORM, and write the initial folder structure. By the time you actually wrote a line of feature code, your motivation was already at 20%.

We called it "boilerplate fatigue."

Fast forward to today. I can open ChatGPT, paste a prompt like "Generate a Next.js 14 boilerplate with Tailwind, Prisma, and NextAuth," and within 30 seconds, I have a fully functioning repository.

AI has fundamentally changed the way we start projects. But it’s also changed the skills we need to be successful.

The Shift from "Typing" to "Architecting"
When AI can write your boilerplate, your API routes, and your basic CRUD operations, the bottleneck is no longer typing speed. The bottleneck becomes system design.

If I don't know how to structure my database, AI will just guess (and often guess wrong). If I don't understand the difference between Server Components and Client Components in React, the AI will generate a mess of hydration errors that I won't know how to debug.

AI doesn't replace the need for fundamental knowledge; it amplifies it. It allows you to skip the boring parts, but you still need to know how the engine works to drive the car.

The New Side Project Workflow
Here is how I build side projects now:

Design the Schema First: Before touching any AI tool, I design the database schema and the core user flow. If the foundation is wrong, the generated code will be a house of cards.

Generate the Scaffolding: I use AI to generate the initial scaffolding, UI components, and basic API routes. (I keep a vault of AI prompts specifically for developers to get the best output).

Review and Refactor: AI code is often "smelly." It works, but it might not be efficient or scalable. I spend my time reviewing the generated code rather than writing it from scratch.

Ship Fast: Because the boilerplate is done in hours instead of weeks, I can actually get to the deployment phase in a single weekend.

The Danger of Over-reliance
The biggest trap developers fall into right now is accepting AI-generated code blindly.

I recently asked an AI to write a complex SQL query. It wrote a beautiful, perfectly formatted query — that used a deprecated syntax and would have locked up the database under heavy load. Because I understood the underlying SQL, I caught it. A junior developer might have pushed it to production.

Use AI as a junior developer. It’s great for writing the repetitive stuff, but you are the senior. You are the one who signs off on the pull request.

What's Next?
We are entering an era where the barrier to entry for building software is lower than ever. But the barrier to building good software is still just as high.

If you are starting a new project this weekend, don't spend hours tweaking your ESLint config. Prompt the AI, generate the base, and focus on the features that actually matter.

If you want to launch your next side project but hate setting up the boring infrastructure, I've packaged my exact step-by-step checklist, Notion workspace, and deployment guide into a Dev Launch Kit. It goes from zero to deployed in a single evening.

And if you want to get the most out of your AI coding assistant, check out the AI Prompt Vault — it has over 500 prompts specifically tailored for developers.

What's your take? Do you use AI for boilerplate, or do you prefer to write it yourself? Let me know in the comments!

Why Your Side Project Dies on Localhost (And How to Actually Ship It)

Oleksandr — Fri, 06 Nov 2026 04:31:22 +0000

Every developer has a graveyard of unfinished side projects.

You know the ones. The brilliant SaaS idea you had at 2 AM. The Chrome extension that was going to change your life. The portfolio site you started to rebuild for the third time because you wanted to try out that new React framework.

You spend weeks in "Tutorial Hell," watching 10-hour YouTube videos, setting up the perfect boilerplate, configuring ESLint, and writing a bulletproof CI/CD pipeline.

And then... you run npm run dev one last time, look at your localhost, and close the terminal. The project never sees the light of production.

Why does this happen? And more importantly, how do you break the cycle?

Here is what I learned after leaving dozens of projects to rot in my local C:\Users\dev\projects folder.

The Trap of "Learning by Building"
We are told that the best way to learn is to build. So we start a project to learn a new stack.

But there is a massive difference between building to learn and learning to ship.

When you build to learn, the goal is to write the most technically perfect code. You refactor constantly. You add state management libraries you don't need. You spend three days configuring a custom Webpack setup just because you can.

When you learn to ship, the goal is to get it into the hands of users. And users don't care about your Webpack config. They care about whether your app solves their problem.

The 3-Step Launch Checklist
If you want to actually ship your next side project, you need to apply the MVP (Minimum Viable Product) mindset.

Here is the exact checklist I use to force myself to launch:

Set a Hard Deadline (and tell people)
Nothing kills a project faster than "I'll finish it when it's ready." It will never be ready.
Pick a date two weeks from today and announce it to the world. Tell your friends, tell your Twitter followers. The fear of public embarrassment is a powerful motivator.
Cut 50% of Your Features
Look at your feature list. Now cross out half of them.
Do you need user authentication for an MVP? No, use a simple magic link. Do you need a custom admin dashboard? No, use Airtable. Do you need a subscription model on day one? No, use a simple checkout link (like Stripe or Lemon Squeezy).

Your only goal is to prove that the core loop works.

Deploy on Day One Don't wait until your code is "clean" to deploy. On the very first day of your project, buy the domain, set up the hosting (Vercel, Netlify, or Cloudflare Pages), and push a "Coming Soon" page. Then, deploy every single time you make a commit.

Seeing your project live on the internet changes your psychology. It stops being a "hobby" and becomes a "product."

The "Post-Launch" Reality
Here is the secret no one tells you: Launching is the easy part.

Once you ship, you will realize that nobody uses your app. You will get zero traffic. And that's completely normal. The real work isn't the code; it's the distribution.

But if you never launch, you can't iterate. You can't get feedback. You can't improve.

What I Use to Ship Faster
Over the years, I've optimized my "Launch Stack." I use Cloudflare for hosting, Notion for my content calendar, and Suby for quick payments.

If you are tired of writing the same boilerplate code and just want to get your idea out the door, I've put together a Dev Launch Kit. It includes my exact launch checklist, a Notion template for tracking your progress, and a guide on how to go from localhost to a live URL in a single evening.

If you are looking to turn your side project into actual income, check out the Side Hustle Starter Pack. It has the frameworks I use to validate an idea before writing a single line of code.

Stop tweaking your package.json. Buy the domain. Deploy the app. Ship the project.

Your future self will thank you.

Have you ever launched a side project? What was the hardest part about actually shipping it? Let me know in the comments!

I Applied Agile to My Personal Life. It Almost Burned Me Out.

Oleksandr — Thu, 05 Nov 2026 07:21:38 +0000

As software engineers, our brains are wired for systems. We love order, optimization, and clear workflows. So, a few years ago, I had what I thought was a genius idea: Why not apply Agile methodologies to my personal life?

If it works for shipping enterprise software, it should work for shipping personal goals, right?

I set up a "Personal Scrum" board. I created a backlog for my life. I broke down my goals into epics, and those epics into user stories. I even held a weekly "retrospective" with myself to identify blockers in my personal life.

It was the most miserable I have ever been.

Here is why applying software engineering principles to your personal life is a trap, and how I fixed it.

The Trap of "Life Technical Debt"
When you treat your life like a software project, you start to view normal human experiences as inefficiencies.

Resting becomes "downtime."

Hobbies become "side quests."

Unfinished books become "technical debt."

I had a Notion dashboard with 47 interconnected databases. I had tags for context, energy levels, and priority. Every time I wanted to do something as simple as "Go for a walk," I had to decide which project it fell under, log it, and check it off.

I was spending more time managing my life than actually living it.

The MVP Mindset Went Wrong
In software, we build an MVP (Minimum Viable Product) to test a hypothesis. But in life, I was trying to build an MVP for my entire existence. I was optimizing for "velocity" instead of "value."

I realized that the human brain doesn't have an API. You can't just scale up your energy levels by adding more coffee and pushing a sprint.

When you introduce high friction into your personal workflow, your brain (the CPU) eventually hits 100% utilization and simply crashes. That's called burnout.

The Refactor: Radical Simplicity
I decided to deprecate the "Life Scrum" system. I deleted all the databases. I threw away the epics and the user stories.

I replaced it with a system that has only one rule: The 3-Task Rule.

Every morning, I write down exactly three things I want to accomplish that day. It doesn't matter if they are work-related, personal, or just "take a nap." Those are my three priorities.

I don't track them in 5 different places. I don't assign them story points. I just do them.

Here is the "architecture" of my new system:
Today:

[ ] Write one section of the new API docs
[ ] Go to the gym
[ ] Cook dinner instead of ordering That's it. No dependencies. No blockers. No velocity charts.

What I Learned
Friction is the enemy of execution. If your productivity system takes more than 10 seconds to open and understand, you will abandon it.

Not everything needs to be a system. Your life is not a Jira board. Some things are just things you do because you're a human being.

Optimize for peace, not just output. A system that helps you ship code but gives you an anxiety attack is a bad system.

The Result
By removing the heavy Agile framework from my personal life, I actually got more done. I stopped procrastinating because I wasn't overwhelmed by a massive backlog of "life tasks."

If you are a developer who feels burned out by your own productivity system, try deleting it. Strip it down to a flat list of three tasks. See how it feels to have a "boring" system.

I eventually got tired of rebuilding my task list from scratch every day, so I built a super minimal Notion template that implements this exact 3-Task philosophy. It has no flashy dashboards, just a clean space to focus on what matters. You can check out the ADHD Daily Planner here.

If you want to read more about why over-engineered Notion templates fail, I wrote about it on my blog here.

How I Automated My Entire Freelance Workflow (And Saved 10 Hours a Week)

Oleksandr — Tue, 03 Nov 2026 15:37:28 +0000

When you start freelancing as a developer, you think your job is 100% writing code.

But the reality is much different. Freelancing is 40% coding, and 60% admin. You have to find clients, send proposals, write contracts, track invoices, chase late payments, and manage project timelines.

If you don't automate the admin work, it will eat into your billable hours and lead to burnout. As developers, we automate our servers and our CI/CD pipelines. We should be automating our business operations too.

Here is the exact stack and workflow I built to automate my freelance business, so I can focus purely on writing code.

The Stack
Notion: The central hub for all client data, projects, and invoices.

Zapier (or Make): The glue that connects all the apps.

Stripe (or Suby/Paddle): To handle the actual payments.

Calendly: For booking discovery calls without endless email ping-pong.

The Workflow: Step-by-Step

Client Intake (The Lead Generation)
I use a simple form (Tally or Typeform) on my website. When a potential client fills it out, Zapier automatically creates a new card in my "Leads" Notion database. It also sends an automated email to the client with a link to my Calendly, so they can book a discovery call immediately.
Proposals and Contracts (The Legal Side)
Once a client is ready to move forward, I don't waste time writing a custom proposal from scratch. I use a pre-made Notion template for my proposals. I share the page with them. It contains the scope of work, the timeline, and the pricing.

Pro-tip: For the contract and NDA, never write them from scratch. Use pre-built templates that have been vetted by a lawyer. I use a Contract & NDA Pack that covers 99% of freelance scenarios. It saves me hundreds of dollars in legal fees.

Invoicing and Payments (The Money) This is where most freelancers waste time. I used to manually generate PDF invoices and send them via email, then set calendar reminders to follow up.

Now, I generate a payment link using Stripe. When the client pays, Zapier listens for the checkout.session.completed webhook. Once triggered, it updates the invoice status in Notion to "Paid" and marks the project as "Active."

Project Kickoff As soon as the payment clears, Zapier automatically creates a shared Slack channel (or a shared Notion workspace) for the client, invites the client, and sends them a welcome message with an onboarding questionnaire.

No manual setup. No "Hey, I just sent the invite" emails. It just happens.

The ROI of Automation
It took me about a weekend to set up these automations. But now, I save roughly 10 hours every single week that I used to spend on admin, copy-pasting data, and writing invoices. That’s 10 extra hours of billable coding time.

If you are a freelancer, look at your workflow this week. Find the most repetitive task (like sending invoices) and automate it. Your future self will thank you.

If you want to skip the setup phase and just grab the exact recipes I use, I have a Zapier Automation Recipes pack here that includes all the triggers and actions.

And if you want to streamline your client experience from day one, check out the Client Onboarding System.

Why Developers Should Treat Their Personal Productivity Like a Microservice

Oleksandr — Tue, 03 Nov 2026 15:35:52 +0000

As developers, we love optimizing our tech stack. We build custom CI/CD pipelines, configure Neovim from scratch, and spend hours tweaking our terminal themes. We understand the principles of good software architecture: separation of concerns, loose coupling, and high cohesion.

But when it comes to personal productivity, we often fall into the same trap: We build a monolith.

I used to have a productivity system that was a massive, tightly coupled monolith. I had a Notion dashboard with 47 different databases. My "Tasks" database was linked to my "Projects" database, which was linked to my "Life Areas" database.

It had a beautiful UI. And it was a nightmare to maintain.

The Monolith Problem
When you build a massive monolith for your personal life, you introduce high cognitive load. Every time you want to do a simple task (like "Buy milk"), you have to decide which database it belongs in, what priority it is, and which tag it needs.

This is the equivalent of refactoring a 10,000-line legacy codebase just to change a button color. Your brain (the CPU) gets exhausted before you even start doing the actual work.

The Microservice Approach to Productivity
If we apply microservice architecture to our daily workflows, the system becomes much more resilient. Here is how I refactored my personal productivity:

Single Responsibility Principle
Your daily task manager should do exactly one thing: show you what to do today. It shouldn't track your 5-year goals, your reading list, and your grocery shopping all at once. Separate them into distinct, isolated pages.
Loose Coupling
Your daily tasks shouldn't depend on your "Life Goals" database being perfectly updated. If your goal tracker breaks or you forget to update it, your daily task list should still work flawlessly.
Statelessness
The best system is the one you can abandon and rebuild in 5 minutes. If your system requires 3 hours of setup, you will never restart it when you fall off the wagon. Keep it simple, flat, and easy to rebuild.

How I Implemented It
I deleted all the relationships. I stripped my task manager down to a single, flat table with just three fields: Task Name, Status, and Date (optional).

I also implemented the "3-Task Rule". Every morning, I pull exactly three tasks from my backlog into my "Today" view. No matter how big the project is, I only see three things. It’s the ultimate way to reduce context switching and avoid decision paralysis.

The Result
My system is boring now. It has no fancy graphs or linked databases. But I ship more code, write more articles, and feel significantly less anxious.

If you are struggling with burnout or just feeling overwhelmed by your own productivity system, try treating it like a microservice. Refactor it. Delete the unnecessary dependencies. Make it boring.

If you want a head start, I actually built a minimalist Notion template that implements this exact 3-task architecture without any of the bloat. You can check out the ADHD Daily Planner here.

Or, if you want to read more about why over-engineered systems fail, check out this article on my blog.

Why Most Notion Templates Fail (And How to Actually Use Them)

Oleksandr — Sun, 01 Nov 2026 15:19:09 +0000

You downloaded a 47-database dashboard. It looked amazing on Twitter. You spent 20 minutes setting it up. You used it for exactly 3 days.

Now it sits in your sidebar collecting digital dust.

As developers, we love optimizing our tools. We build custom CI/CD pipelines, configure Neovim from scratch, and spend hours tweaking our terminal themes. But when it comes to personal productivity, we often fall into the same trap: Over-engineering the system instead of doing the actual work.

Here is why most Notion templates fail, and how to build a system that actually sticks.

The Problem: Cognitive Overload
Most templates fail because they are designed to look impressive, not to be used daily.

They have:

Too many databases (Tasks, Projects, Areas, Resources, CRM...)

Too many required properties (Status, Priority, Energy Level, Context...)

Too much friction.

When you open Notion and see a dashboard that requires you to fill out 5 different fields just to log a single task, your brain will do everything in its power to avoid opening it.

For developers (and especially for those of us with ADHD), friction is the enemy of consistency.

The Solution: The "3-Task" Rule
To fix this, we need to strip the system down to its bare minimum.

Instead of a massive "Life OS" with 50 interconnected databases, start with a single, flat database.

Limit your daily focus Your daily dashboard should only show you 3 tasks. Not 30. Not 10. Three.

Why 3? Because it forces you to prioritize. If you finish them early, you can pull from a "Backlog" or "Next" list. But waking up to a list of 40 tasks is a guaranteed recipe for decision paralysis.

Remove the properties Delete the "Energy Level" and "Context" fields. Keep only:

Task Name (Title)

Status (To Do, In Progress, Done)

Date (Optional, only if it has a hard deadline)

That’s it. If you need to add notes, put them in the page body, not in a new database property.

Automate the reset One of the biggest reasons people stop using a system is that it gets cluttered. You need a way to archive completed tasks automatically. In Notion, you can use a simple filter: Status is not Done for your daily view. The moment a task is checked off, it disappears.

How to make it stick
The perfect productivity system is the one you actually use. It doesn't need to look good on a screenshot; it needs to be fast.

If you are a developer, treat your Notion setup like a microservice. It should be:

Stateless: You can delete it and start over without losing your mind.

Decoupled: Your daily tasks shouldn't depend on your quarterly goals database being perfectly updated.

Fast: Opening your dashboard should take 0 mental effort.

What's next?
I recently wrote a deep dive on how to set up a minimalist Notion workspace that actually gets used, especially if you struggle with ADHD or burnout.

👉 Read the full guide on our blog: Why Most Notion Templates Fail

If you want a head start, we built a Minimalist ADHD Daily Planner that uses the 3-task rule. No fluff, no 47-databases. Just a clean, distraction-free interface to help you ship your tasks.

👉 Check out the ADHD Daily Planner here

What does your Notion setup look like? Do you prefer complex systems or minimalist lists? Let me know in the comments! 👇

How I Generated a 500-Page Localized Site Using Only PowerShell

Oleksandr — Wed, 28 Oct 2026 17:52:34 +0000

As developers, we have a bad habit of over-engineering everything.

When I decided to build jsonexlab.com to sell my focused Notion templates, my first instinct was to spin up a Next.js app. I thought: "I'll need a database for the products, i18n for the languages, and a CMS for the blog."

But then I looked at the requirements. I wasn't building a complex SaaS with user authentication. I was building a static catalog of digital products.

So, I did something crazy. I deleted the Node.js setup, opened PowerShell, and wrote a script to generate raw HTML. Here is how I did it, and why it works.

The "No Framework" Stack

Hosting: Cloudflare Pages (Free tier, unlimited bandwidth).
Generation: PowerShell scripts.
Styles: Plain CSS.
Payments: Suby (Crypto).
Email: Web3Forms + Make.com + Brevo.

The result? A site with 500+ pages in 28 languages, zero hydration errors, zero JS bundles, and load times measured in milliseconds.

The Challenge: Translating 28 Languages

I wanted to sell my templates in Europe, Asia, and South America. That meant 28 different languages.

Doing this manually in React would have been a nightmare of JSON translation files. Instead, I wrote a PowerShell script that took my base English HTML file and applied a dictionary of translations to it.

Here is a simplified version of how the localization script works:


powershell
$translations = @{
    "es" = @{
        "You might also like" = "También te puede gustar";
        "Get PDF" = "Obtener PDF";
    }
    "de" = @{
        "You might also like" = "Das könnte dir auch gefallen";
        "Get PDF" = "PDF erhalten";
    }
}

foreach ($lang in $translations.Keys) {
    $html = [System.IO.File]::ReadAllText("base-template.html")

    foreach ($key in $translations[$lang].Keys) {
        $html = $html -replace [regex]::Escape($key), $translations[$lang][$key]
    }

    # Save to /es/index.html, /de/index.html, etc.
    [System.IO.File]::WriteAllText("$lang/index.html", $html)
}
To make Google happy, I also had to inject proper hreflang tags for all 28 languages into every single page. A simple loop handled that too.

The Real Challenge: Keeping Track of 30 Products
While the technical generation was fast, the business side was a mess. I had 30 different products: Debt Simulators, Freelancer Invoices, ADHD Planners.

I was losing my mind trying to remember which product was linked to which blog post, or which language version needed updating.

I realized I was trying to build a system for my system. So, I built a simple Notion dashboard (ironically, using the same "anti-bloat" philosophy I sell).
I tracked:

Product Status: (Draft, Finished, Live)

The Link Tree: (Which blog post links to which product)

The Tech Checklist: (Does it have an OG image? Is it in the sitemap?)

The Results
Speed: Because it's just static HTML, Cloudflare serves it instantly. No React hydration, no API calls, no database queries.

Cost: $0/month.

SEO: Because I control the raw HTML, I could perfectly inject JSON-LD schema (Product, BreadcrumbList, BlogPosting) without fighting a framework.

When Should You Do This?
If you are building a complex app with user accounts and real-time data, do not use PowerShell. Use Next.js, Remix, or whatever makes you happy.

But if you are building a content site, a landing page, or a digital product catalog, try going back to basics. Write a script that generates raw HTML. You might be surprised at how fast and simple it is.

How I Generated a 500-Page Localized Site Using Only PowerShell

Oleksandr — Wed, 28 Oct 2026 06:47:42 +0000

As developers, we have a bad habit of over-engineering everything.

But then I looked at the requirements. I wasn't building a complex SaaS with user authentication. I was building a static catalog of digital products.

So, I did something crazy. I deleted the Node.js setup, opened PowerShell, and wrote a script to generate raw HTML. Here is how I did it, and why it works.

The "No Framework" Stack

Hosting: Cloudflare Pages (Free tier, unlimited bandwidth).
Generation: PowerShell scripts.
Styles: Plain CSS.
Payments: Suby (Crypto).
Email: Web3Forms + Make.com + Brevo.

The result? A site with 500+ pages in 28 languages, zero hydration errors, zero JS bundles, and load times measured in milliseconds.

The Challenge: Translating 28 Languages

I wanted to sell my templates in Europe, Asia, and South America. That meant 28 different languages.

Here is a simplified version of how the localization script works:


powershell
$translations = @{
    "es" = @{
        "You might also like" = "También te puede gustar";
        "Get PDF" = "Obtener PDF";
    }
    "de" = @{
        "You might also like" = "Das könnte dir auch gefallen";
        "Get PDF" = "PDF erhalten";
    }
}

foreach ($lang in $translations.Keys) {
    $html = [System.IO.File]::ReadAllText("base-template.html")

    foreach ($key in $translations[$lang].Keys) {
        $html = $html -replace [regex]::Escape($key), $translations[$lang][$key]
    }

    # Save to /es/index.html, /de/index.html, etc.
    [System.IO.File]::WriteAllText("$lang/index.html", $html)
}

Stop Building Massive 'Second Brain' Dashboards. Here’s the Anti-Bloat Approach.

Oleksandr — Tue, 27 Oct 2026 13:57:05 +0000

Let me guess what happened with your last Notion setup.

You watched a video about "the ultimate second brain." You downloaded a template with 47 databases, 12 relations, and a dashboard that looked like a NASA control panel. You were excited for two days. By day four, you had 300 unread items, you were anxious every time you opened it, and you quietly archived the whole thing.

As developers, we love over-engineering. We love building complex systems. But when it comes to managing our own lives, freelancing, or tracking our finances, complexity is the enemy.

The Problem with "Ultimate" Templates

Most productivity templates are built for the sake of the template, not the user. They give you more:

More databases ("so you can track everything")
More views ("switch between kanban, calendar, timeline, table")
More customization

But more is the opposite of what a busy brain needs. What it needs is less, but clearer.

The "Anti-Second Brain" Approach

I got so tired of this that I built my own collection of templates. I did the opposite of what the "Notion gurus" do.

I built 30 tiny, focused systems. Each one solves exactly one problem. No bloat. No 47 databases.

Here are the three rules I follow:

One problem per template. If it's an invoice system, it doesn't have a habit tracker attached. When you open it, you know exactly what to do.
It must fit on one screen. If you have to scroll to find the main view, the design has failed.
A clean "done" moment. When you finish using it, you should know you're done. Close the tab.

For Example: The Freelancer's Invoice System

Instead of an "Ultimate Life OS", I built a Client & Invoice System. It tracks clients, projects, and overdue invoices. Nothing else.

Every freelancer has the same problem: a client owes you $1,200 for work you finished two weeks ago, and you keep forgetting to send the follow-up email.

A focused system fixes this in one place. It replaces Bonsai or FreshBooks, and it saves 2–3 hours a week.

(If you're curious, you can see the exact system I use here: jsonexlab.com.)

The Tech Stack Behind the Site (Build in Public)

Since this is Dev.to, I want to share how I actually shipped this. I didn't use Next.js or React. I wanted raw speed.

Hosting: Cloudflare Pages (free tier).
Generation: The entire site (500+ pages across 28 languages) is generated using PowerShell scripts. Yes, raw HTML/CSS generation.
Localization: Automated hreflang injection and content translation using dictionary maps in scripts.
Payments: Currently using Suby (crypto). Working on getting fiat approval.
Automation: Webhooks -> Make.com -> Brevo for email delivery.

It's a monolith of static HTML files, and it loads in milliseconds. No build step, no hydration errors, just raw HTML. It's ugly and beautiful at the same time.

The Bottom Line

If you're a developer, stop trying to build a "second brain" with 47 databases. Build a few simple walls to keep yourself focused. Your future self will thank you.

Have you ever abandoned a complex Notion setup? What was the breaking point?

The ADHD-Friendly Notion Setup That Actually Works

Oleksandr — Mon, 26 Oct 2026 17:30:26 +0000

Let me guess what happened with your last Notion setup.

You watched a YouTube video about "the ultimate second brain." You downloaded a template with 47 databases, 12 relations, and a dashboard that looked like a NASA control panel. You were excited for two days. By day four, you had 300 unread items, you were anxious every time you opened it, and you quietly archived the whole thing.

If you have ADHD, this story is not an exception. It's the rule. And the problem is not you. The problem is the template.

Why most Notion templates fail ADHD brains

Notion is a blank canvas. ADHD brains hate a blank canvas. They need walls — clear boundaries, clear next steps, clear "you're done."

Most templates give you more: more databases, more views, more customization. More is the opposite of what an ADHD brain needs. What it needs is less, but clearer.

The 3-task rule

Every morning, you open Notion and you see exactly 3 tasks. Not 10. Not "all tasks due today." Three.

Why three?

It's achievable. You can finish 3 tasks in a day, even on a bad day. That means you win the day. Winning compounds.

It kills decision paralysis. You don't have to choose what to do. The system chose for you last night.

It creates a clean "done" moment. When the 3 are checked, you're done. Not "done for now." Done. That's a rare thing for ADHD brains.

How to set it up (10 minutes, not 10 hours)

Step 1 — One database, three fields. Create a Notion database called "Daily." Fields: Task, Date, Done. That's it. No tags, no priority, no "energy level." Every extra field is a decision you'll be forced to make 20 times a day.

Step 2 — One view, filtered to today. Filter: Date is Today AND Done is unchecked. This is the view you open every morning.

Step 3 — The night-before ritual. Before you close your laptop, add three tasks for tomorrow. Then close it. Don't add tasks during the day. If something urgent comes up, put it in a separate "Later" page.

What about the 100 other things you're tracking?

You don't track them. You park them. Have a "Later" page (one page, not a database). Whenever a thought pops up, write one line and move on. Once a week, scan and promote or delete.

The shutdown ritual

At end of each day: check off completed tasks, move incomplete ones to tomorrow, close the laptop. This is not productivity theater. This is the difference between a brain that stays "on" all night and a brain that can rest.

The one thing that kills these systems

It's not forgetting. It's rebuilding. At some point you'll think "I should add a project tracker." That's the moment it dies. If you need to track a project, use a separate page. Don't add it to the daily view.

If you're a Notion power user, this feels wrong. If you have ADHD, it feels like relief. That's the point.

How Cloudflare D1's Daily Write Limit Almost Broke My Sanctions App (and How I Fixed It)

Oleksandr — Mon, 26 Oct 2026 12:48:32 +0000

I built a compliance engine that checks names against global sanctions lists (OFAC, UK, EU, UN). It runs entirely on Cloudflare Workers and D1. It’s fast, cheap, and mostly runs itself.

Until I woke up to a completely dead ingestion pipeline.

Here is the exact error that greeted me in my GitHub Actions logs:

{
"success": false,
"errors": [{
"code": 7500,
"message": "Your account has exceeded D1's free tier daily row write limit. Upgrade to a paid plan or wait until tomorrow (midnight UTC) to continue."
}]
}
My first thought was a bug in my code. But the truth is simpler: D1's free tier allows 100,000 row writes per day, and my ingestion scripts ate through them before lunch.

Here is what happened, why it’s a common trap, and the architecture changes I made to fix it.

The Trap of "Just Upsert Everything"
My initial ingestion logic was naive. I used a standard INSERT ... ON CONFLICT DO UPDATE (upsert) to sync records from the UN, OFAC, and GLEIF lists into my D1 database.

I thought: "If the record hasn't changed, it won't cost me anything."

That's true for standard Postgres, but D1 charges you for the INSERT attempt, even if the ON CONFLICT clause ends up doing nothing.

When I pulled the UN consolidated list (about 2,000 records) and the GLEIF database (tens of thousands of entities), my script tried to upsert everything at once.

33,000+ sanctions records

Plus daily cron jobs for OFAC, PEP, and UK lists

Plus API search logs

Very quickly, I hit the 100,000 writes/day ceiling. D1 locked my database in read-only mode.

How to Fix It (The 3-Layer Approach)
To survive on the free tier, you have to treat D1 writes like gold. Here is how I refactored my ingestion pipeline.

The WHERE Clause is Your Best Friend
If you are doing an upsert, you should only actually write to the row if the data has changed. You can add a WHERE clause to your DO UPDATE statement.
INSERT INTO sanctions (
list_code, entity_id, name, name_normalized, programs
) VALUES (?, ?, ?, ?, ?)
ON CONFLICT(list_code, entity_id) DO UPDATE SET
name = excluded.name,
programs = excluded.programs
WHERE
sanctions.name != excluded.name OR
IFNULL(sanctions.programs, '') != IFNULL(excluded.programs, '');
By adding this WHERE clause, D1 skips the write if the row is identical. This alone saved me thousands of writes on daily runs where only 1% of the data actually changed.
Chunking and MAX_PAGES_PER_RUN
My second mistake was trying to ingest the whole world in one run. GitHub Actions have a 6-hour limit, but your D1 quota doesn't care about your workflow time; it cares about rows.

If you have a massive dataset (like GLEIF), you need an incremental cap. I added an environment variable to my workflow:
env:
MAX_PAGES_PER_RUN: '20' # Never ingest more than 20 pages in a single run
Then, in the script, I break the loop once the limit is reached, saving the offset for the next run. It’s slower to backfill, but it guarantees your database won't go offline.

Separate the "Read" and "Write" Phases Originally, I fetched data from the API and wrote it to D1 in the same loop. If the API rate-limited me halfway through, I’d have a half-written database.

Now, I use a two-step pipeline:

Fetch Phase: Download the raw XML/CSV to Cloudflare R2 (Object Storage). R2 has a very generous free tier (10GB/month).

Parse & Ingest Phase: Read the file from R2, parse it, and batch-write to D1.

This decoupling means if D1 hits a quota limit, the fetch phase still succeeds. Tomorrow, I can just run the parse phase against the data sitting in R2 without re-downloading it.

What If You Hit the Limit Today?
If you are already locked out, there is no magic bypass. You have to wait until 00:00 UTC.

But you can prepare. Here is the exact check I run in my terminal before triggering a heavy job:
npx wrangler d1 execute compliance-db --remote --command="SELECT COUNT(*) FROM sanctions"
If it's read-only, the command will fail with code 7500 or code 7403. Don't panic—it's just Cloudflare telling you to take a break.

Final Thoughts
Cloudflare D1 is incredible for read-heavy edge applications. It’s practically free and sits right next to your Workers. But it’s not a Postgres replacement for heavy ingestion pipelines.

If you are building a scraper or an ETL pipeline on D1, idempotent upserts and strict batch sizes are not optional. They are the difference between a running app and a dead one.

(If you're building compliance or data tools on Cloudflare and want to compare notes on D1 limits, feel free to drop a comment or reach out.)