Forem: Maksym Kunytskyi

So what should we call developers who write regular code? Not a vibe coder, not a low-coder. Maybe an organic developer? <3

Maksym Kunytskyi — Wed, 27 Aug 2025 13:13:23 +0000

The AI “Revolution” Is Still Stuck in a Chatbox

Maksym Kunytskyi — Thu, 21 Aug 2025 20:50:40 +0000

I’ll be honest: I’m tired of hearing about the “AI revolution.”

It’s 2025. Trillions have been spent on models. And what’s the big breakthrough in interfaces?
Still the same old chatbox.

No branches.
No canvases.
No merging mindmaps.
Just a text field with a scrollbar.

I’ve personally tried a bunch of the “next-gen” ideas: visual workspaces, graph schemes, even those fancy “AI-IDEs” with integrations.

And every time it ends the same way: you’re back in chat.

Why? Because business doesn’t care how pretty the UI looks. It cares about one thing: does it output JSON or text I can plug into my pipeline?

Those Dribbble-friendly demos of “branching canvases” are cool until you try them in practice.

Branches collapse under complexity.
Canvases become chaos the moment you leave the demo stage.
Mindmaps? Fun, but impossible to keep reproducible.

Chat keeps winning because it kills friction.
Open. Type. Answer. Done.

But here’s the irony that bugs me the most:

AI today is strong enough to write its own code, compose music, analyze markets… and yet we force it into chat bubbles that feel like the 80s.

Want flexibility? You still have to prompt.
Want to fork? Copy everything into a new chat.
Want alternatives? Do it by hand.

It feels like Excel in the 90s, just wrapped in an LLM.

So here’s where I’m stuck:

AI is definitely getting faster, cheaper, more accurate.
But it’s not getting deeper.

As long as everything lives inside a chatbox, there’s no branching thought, no merging ideas, no real multidimensionality.

And I can’t shake this question:
Are we really going to sit inside chat windows for the next five years?

Or is it finally time to build something where thoughts can branch, merge, and collide?

Because right now, what we’ve got isn’t a “thinking environment.”
It’s just a super-browser for text.

I don’t have the solution yet.
Maybe chat is the final form — the simplest way to interact with intelligence.

But part of me hopes someone out there is already working on the next environment for thought.

What do you think?
Are we stuck with chat, or is the next interface revolution just waiting to break out?

Everyone talks about the “AI revolution.” That interfaces are about to change forever. But it’s 2025, trillions spent, and the only real interface we still have? 👉 A chatbox.

Maksym Kunytskyi — Thu, 21 Aug 2025 20:44:22 +0000

What cookie consent libraries do you use? 🍪 Looking for something easy to integrate, multi-language, customizable, and GDPR-friendly. Do you prefer big tools like Cookiebot/OneTrust or lightweight open-source solutions?

Maksym Kunytskyi — Thu, 21 Aug 2025 14:48:02 +0000

From MVP to Product: How I Built a SaaS App Without Writing a Line of Code

Maksym Kunytskyi — Thu, 17 Jul 2025 21:29:24 +0000

From MVP to Product: How I Built a SaaS App Without Writing a Line of Code

Yes, it's real. Yes, it works. And no, you don't need to touch VS Code.

Let’s get one thing straight: you no longer need to write code to build and launch a serious SaaS product. In 2025, your competitive edge isn't knowing the latest JavaScript framework — it's knowing how to build fast, validate, and ship without burning cash.

This is how I (or you!) can build a fully functioning SaaS platform using only no-code tools like Webflow, Xano, Airtable, Zapier, and a bit of smart thinking. Whether you're a founder, solo maker, or a dev trying to escape boilerplate hell — this article shows how to launch a real business product, step by step.

💡 The Idea

Let’s say the product is: a platform for fitness coaches to manage clients, send workouts, and receive feedback.

Call it: FitFlow.

The core features:

Coach can create workout programs
Clients can view workouts and send feedback
Weekly reports auto-sent to coaches
Payments + subscription logic

Sounds like something that needs a backend, user auth, database, dashboards, emails, right?

Yes. But you can do it all — without code.

🏗 Step 1: Visual Front-End with Webflow

Webflow is the foundation. Here’s what we use it for:

Landing page
Pricing page
Client dashboard (via gated content)
Login/signup/reset flows (with Memberstack or Wized)
Admin area for coaches

Tools integrated with Webflow:

Memberstack (user auth + subscriptions)
Wized (to power dynamic dashboards)
Finsweet Attributes (for filtering, CMS logic)

👉 Webflow gives us a pixel-perfect UI that looks custom-built. And the best part? No messing with CSS or frontend state management.

🧠 Step 2: Backend Logic with Xano

This is where the magic happens.

Xano is your no-code backend that:

Stores all data (users, workouts, sessions, feedback)
Manages user roles and permissions
Sends weekly report emails
Connects to external services (email, Stripe, etc)

What we build in Xano:

API endpoints (e.g., GET workouts, POST feedback)
DB tables for users, coaches, workouts, sessions, feedback
Logic: When a client submits feedback → store it → notify coach
Scheduled tasks: every Sunday → send progress email to coach

It’s as scalable and fast as Firebase or Supabase — but visual.

📊 Step 3: Admin & Data Layer with Airtable (Optional)

While Xano stores primary data, Airtable is great for:

Quick admin views (e.g., list of active clients, feedback logs)
Internal use (e.g., a manual override of client status)
Connected automations

You can sync Airtable with Zapier or Make.com to automate tasks like:

Send Slack notification when a new client signs up
Add a new client to Airtable with default fields

🔄 Step 4: Automation with Zapier / Make

Zapier acts as the glue between tools.

Examples:

When a user signs up (via Memberstack) → send welcome email (Gmail)
When a coach creates a new workout → notify client (Email or SMS)
When payment fails → alert coach

Pro tip: Use Make for more complex logic (like mapping dynamic data).

💳 Step 5: Payments & Subscriptions

Handled via Memberstack + Stripe:

Coach selects plan → triggers Stripe checkout
Memberstack handles access levels (free, premium, pro)
Xano checks access via API to limit certain features

No backend code. No PCI compliance nightmares.

🔐 User Authentication

Handled entirely via Memberstack or Wized + Xano.

Two paths:

Easy way — let Memberstack manage signup/login
Full control — use Wized + Xano API for login/auth logic

Option 2 gives you more power: email verification, onboarding, referral tracking, etc.

📬 Emails and Reports

Use:

Xano: Scheduled functions + dynamic content
SendGrid / MailerLite: Email templates

Every Sunday:

Xano runs GET feedback for past 7 days
Generates progress summary
Sends via SendGrid to coach

No loops, no SMTP headaches. Just visual logic.

🧪 Beta Testing & Feedback

Set up a private beta in Webflow:

Sign-up form → adds user to Airtable
Send Calendly link for onboarding
Feedback form via Webflow or Typeform → saves to Xano

Launch your MVP with 5–10 early users and iterate based on real usage.

📈 Scaling? No Problem

These tools handle thousands of users with ease.

Want to scale further?

Migrate Xano endpoints to Supabase or custom API later
Export Webflow to codebase (if needed)
Replace Zapier with microservices

80% of SaaS businesses never need to rewrite.

✅ Summary: Stack Overview

Function	Tool
Frontend	Webflow + Wized
Auth	Memberstack / Xano
Backend	Xano
Database	Xano / Airtable
Payments	Stripe via Memberstack
Automations	Zapier / Make
Emails	SendGrid / MailerLite

🧠 Final Thoughts

If you’re a solo founder, indie hacker, or dev tired of reinventing CRUD — this approach gives you:

⚡ Speed (MVP in weeks, not months)
🔁 Flexibility (change logic in hours)
🎨 Pro UI (without frontend pain)

You can literally build a SaaS product in your browser.

And no, this isn’t cheating.

This is building smart.

Like this? Follow for more on no-code stacks

How Many Technical Calls Do You Really Need?

Maksym Kunytskyi — Sun, 01 Jun 2025 05:47:22 +0000

Lately, I’ve been thinking a lot about technical meetings.

You know — those syncs, standups, grooming sessions, “quick” clarifications, architecture overviews, retro deep-dives, async that turns into sync, and everything in between.

How many of them do we really need?

I say this as someone who enjoys teamwork — but I’m starting to believe we’re seriously overdoing it.

What I’ve noticed 👇

A “quick call” often turns into a 30–45 minute rabbit hole.
Meetings interrupt deep focus. Even a 15-minute sync at 11:30 AM can ruin an entire productive morning.
Half the time, the same question could be resolved in 3 Slack messages or a Loom video.
The more people in the call — the less productive it usually is.

And most importantly:

More meetings ≠ more alignment.

Often, they’re a symptom of unclear specs, weak async culture, or trust issues.

So what’s the alternative?

Here’s what has worked for me (and the teams I’ve led):

1. ✍️ Better async workflows

Write clearer tickets. Record short Loom videos. Share architecture ideas in Notion or GitHub Issues.

2. 🎯 Fewer people in the room

Not every engineer, PM, and designer needs to be in every call.

3. ⚙️ Smarter default behaviors

Ask: “Can this be a doc?” → If yes, make a doc.

Ask: “Do I really need live feedback?” → If not, write it up.

4. 🧭 Push ownership

When developers are trusted to make technical decisions and document them, calls become rare and more impactful.

Not anti-meeting, just anti-waste

Don’t get me wrong — I’ve had great technical calls.

Collaborative design sessions, real-time debugging, or architecture whiteboarding can be amazing. But they should be the exception — not the default.

If you're in meetings all day and wondering why you're shipping less — this might be your answer.

What about you?

How many technical calls do you have each week?
How many of them could be async?
What helps your team reduce meeting overload?

Let’s share ideas below 💬

How Low-Code Databases Are Reshaping the Way We Build Products (And Why I’m Betting on Them)

Maksym Kunytskyi — Sat, 31 May 2025 21:32:51 +0000

How Low-Code Databases Are Reshaping the Way We Build Products (And Why I’m Betting on Them)

Hey folks, Maks here 👋 CTO at Microns.io and Webflow/low-code mentor. After a few years of building full-featured products with surprisingly tiny teams, I’m convinced that low-code databases are the real deal—and they’re flipping the script on how we think about app development.

I’ve used them to launch global platforms, ship real features in weeks instead of months, and collaborate with non-tech teammates in ways I didn’t think were possible a few years ago. So let me share how low-code backends like Xano, Airtable, Supabase, and friends are changing the game—and why you should care.

From Skeptic to Believer: My Journey

Let’s rewind to 2023. I got hired to lead the rebuild of Microns.io—a marketplace for buying and selling micro-startups. We needed to go live fast, but we didn’t have a full-stack engineering team, just a clear vision and a ton of ideas from users.

The answer? A full low-code stack: Webflow for the frontend, Wized as the logic layer, and Xano as our backend database and API builder.

Sounds risky? It was. But it worked. In 6 months, we shipped a complete platform: user dashboards, offer workflows, real-time chat, email triggers, analytics, CRM. No traditional codebase. Just low-code.

Now, it’s 2025—and I see even more potential. Low-code databases aren’t just for MVPs anymore. They’re production-ready, scalable, and honestly, kind of fun to work with 😄

Why Low-Code Databases Are (Finally) Worth It

You skip the boilerplate: Auth, CRUD, filtering, pagination? Done in minutes.
Fast iterations: Need a new field in your schema? Add it in the UI—done. No deploys, no downtime.
Works great with no-code frontends: Especially tools like Wized or FlutterFlow.
Perfect for lean teams: You can ship with 1-2 people what used to take 5-6 devs.
Way cheaper: No need for a dedicated DevOps pipeline. Less infra, less headaches.

And look—I’m not saying it replaces all custom code. You’ll still need it for edge cases. But for 80% of modern SaaS use cases? Low-code is plenty.

What You Can Actually Build With It

Here’s what we built on Microns with low-code DBs:

Marketplace listings with filters and saved searches
Secure user profiles with custom roles
Stripe-integrated offers and escrow logic
Real-time chat with email fallbacks
Weekly digests + transactional emails
Admin CRM panel with notes, actions, and moderation tools

All managed through Xano, connected to the frontend with Wized.

And no, it’s not just for marketplaces. I’ve seen:

B2B SaaS MVPs (billing + access control in a weekend)
Inventory management tools
Internal dashboards and analytics
Client portals for agencies
Education platforms with quizzes, scores, and chat

What to Watch Out For

Okay, it’s not all roses 🌹. Some stuff you should know:

Scalability: Most low-code DBs will handle thousands of users, but for millions? You’ll need to test.
Vendor lock-in: Choose platforms with good export/backup options.
Debugging: Not as easy as digging through code sometimes.
Docs/UI quality varies: Some tools are better than others—read reviews.

Still, I’ll take these trade-offs if it means shipping faster and validating ideas early.

Why It Matters Right Now

The world’s changing. Budgets are tight, timelines are short, and everyone’s trying to ship smarter—not harder. Low-code tools let founders, indie hackers, and small teams compete with companies 10x their size.

You don’t need to know SQL or manage AWS. You just need the idea, some logic, and the right tools.

Low-code databases turn builders into founders.

If you’re still building everything from scratch in 2025...why?

TL;DR: My Hot Take

Low-code databases aren’t a toy—they’re production-ready.
Perfect for solo devs, founders, and lean startups.
I’ve shipped full-featured platforms like Microns with them.
The future is fast, and low-code is the way to get there.

I’d love to hear your thoughts! Are you using low-code backends? Got a cool stack you want to share?

Drop a comment or hit me up on Twitter or LinkedIn. Always happy to chat tech.

And if you’re curious how we used Xano + Webflow + Wized to rebuild a startup marketplace from scratch, check out my earlier post: How We Built Microns

30 Things I Wish I Knew Before I Started Web Development

Maksym Kunytskyi — Sat, 31 May 2025 21:26:44 +0000

After years of building products, mentoring, and making (a lot of) mistakes, I decided to write this list.

Whether you're just starting or already on your journey, I hope this helps you avoid a few traps and move faster.

1. You don’t need to know everything before building.

You’ll learn the most by doing — not by waiting until you feel “ready.”

2. HTML and CSS are more powerful (and complex) than you think.

Layouts, responsiveness, and browser quirks take time to master.

3. JavaScript will confuse you — that’s normal.

Scopes, closures, and async logic are tough at first, but clarity comes with practice.

4. You can break production with a missing semicolon.

Small mistakes can have big consequences — attention to detail matters.

5. Frameworks change, fundamentals don’t.

Learn the core web concepts; tools come and go.

6. **Understanding the why behind code is more important than copying the how.**

You’ll solve problems faster when you understand what’s happening under the hood.

7. Tutorials are helpful — until they become a crutch.

Don’t just follow along. Try building something without instructions.

8. Being stuck is part of the job.

Frustration is normal; persistence is what sets you apart.

9. Googling is a skill. Learn it.

Knowing how to ask the right questions saves hours.

10. You don’t have to build the backend from scratch. Use tools.

No-code, low-code, and BaaS tools can get you to market faster.

11. Design matters. Learn at least basic UX/UI.

Users won’t care how elegant your code is if the interface is confusing.

12. Writing clean code is harder than writing working code.

Maintainability becomes critical as your projects grow.

13. **Code comments aren’t for others — they’re for future you.**

Your brain won’t remember why you did that thing in three months.

14. Copying Stack Overflow is fine. Not understanding it is not.

Always know what each line is doing before pasting it into your app.

15. Break big problems into tiny ones.

Small wins keep you motivated and make complex projects manageable.

16. Time spent planning saves time debugging.

Jumping in without a plan leads to chaos.

17. You don’t need a CS degree to be a great dev.

Passion, consistency, and curiosity matter more.

18. Your first portfolio will suck. It’s okay.

Done is better than perfect — just ship it.

19. Debugging is 80% of your time. Embrace it.

Finding the bug is often harder than fixing it.

20. Learn Git early. And back everything up.

Version control saves careers. Don’t skip it.

21. You will write bad code. You’ll survive.

It’s part of the journey. Learn and refactor.

22. Don’t overengineer things. MVP is your best friend.

Get feedback early instead of building in isolation.

23. Naming things is harder than expected.

Clarity beats cleverness. Name variables like you're explaining them to someone new.

24. Soft skills matter more than you think.

Communication, empathy, and teamwork open more doors than perfect code.

25. Talk to real users before you build.

Your assumptions are often wrong — and that’s okay.

26. Coding is creative work. Don’t burn out.

Rest is productive. Take breaks often.

27. Sleep helps fix bugs. Seriously.

A tired brain misses obvious things. Sleep on it.

28. Pair programming teaches you a lot — fast.

Watching others code (and being watched) accelerates learning.

29. Build real projects. Fake ones don’t stick.

Solve real problems and your skills will grow naturally.

30. You’ll never feel like you “know enough.” Start anyway.

The imposter syndrome never really goes away — just begin.

🧠 Over to you!

If you’re a few years into your dev journey — what do you wish you knew earlier?

Let me know in the comments. I’d love to grow this list together 💬

How we built Microns on a full low-code stack — and launched globally in 6 months

Maksym Kunytskyi — Thu, 29 May 2025 15:25:35 +0000

Hi! My name is Maksym Kunytskyi, CTO at Microns. I’d like to share my personal experience of building a marketplace based on low-code/no-code technologies.

Below I’ll talk a bit about the challenges we faced, why this model works, and why it’s worth considering for anyone building digital products — especially with a limited budget.

For almost two years now, I’ve been working as CTO on a project called Microns.io — a marketplace that connects startup owners with businesses valued up to $1 million to buyers who are interested in acquiring them. The platform now has over 10,000 users and continues to scale and grow. But it wasn’t always this way.

How It All Started
Microns started as a simple MVP built with Webflow and a few external services like Memberstack. It was cheap, fast, and good enough to test the hypothesis and gather the first users. That’s exactly why the founder, Illia, chose the low-code approach: cost-effectiveness, fast development, and an already-familiar environment that allowed for rapid changes without needing a full development team.

Like most MVPs, it was very raw. Essentially, it was a website with basic paid access via Memberstack, minimal page protection, a few plugins, and manually updated content. But it worked — we saw real demand.

I joined the team when the product had already gathered some traction and it was time to scale. We all understood: the longer we stuck with the old stack, the more we were turning it into a Frankenstein — where each new feature was a patch on top of another. So we had to decide: rewrite everything using a traditional stack or take the risk of building a scalable platform still within the low-code paradigm.

We decided to take the risk — and we didn’t regret it.

The Transition Strategy: Choosing the Stack
I suggested the following stack:

Webflow — for layout and UI
Wized — for frontend logic
Xano — for the backend, database, and API

This setup allowed us to avoid hiring a full-stack team in the early stages and stay as flexible as possible.

Webflow
Webflow is more than just a website builder, as it’s often referred to. It’s a full environment for creating UI/UX. You control every pixel, you can build any design, create CMS collections, use animations, and — if something’s missing — embed custom JS directly into elements. I have a lot of experience with this platform, I’m practically an ambassador for it, so the decision was obvious.

Frontend work was the easiest part for me. My background as a Webflow developer allowed me to build out the whole app interface quickly.

Wized
Wized allows you to connect Webflow to the backend and add full frontend logic without writing code. It acts as a layer that handles requests, rendering, authentication, user states, dynamic routes, cookies, localization, and more.

When we started in the summer of 2023, it was still quite raw. But I had already used products from the Finsweet team and trusted them. After testing alternatives (there were almost none), I realized — it’s either Wized or a custom frontend. We chose Wized despite its limitations — and we don’t regret it.

As part of my research, I created a prototype using Wized and realized: it’s time to launch and build.

Wized pros:

Easy integration
Fast to get started
Full integration with Webflow
Can implement complex logic without JS

Wized cons:

Was unstable in the early stages (no longer a current issue, but worth mentioning)
Limited documentation (though manageable for JS developers — I struggled because I’m not a JS dev)

Wized Interface:

Xano
Xano is the king (or queen) of no-code backend platforms. It’s an API-first environment where you can build a database, API endpoints, trigger-based logic, error handlers, conditions, filters, caching, and much more. It supports relational data, nested structures, server-side auth, and even CRON tasks.

I compared it to Supabase and Firebase, but Xano allowed us to start quickly and scale gradually. I drafted the first version of our database — and everything just flowed.

Really flexible database management in Xano:

Xano pros:

Full-featured API infrastructure
Highly flexible
Great documentation and community support

Xano cons:

Steep learning curve if you don’t have prior backend experience You can really manage your data models flexibly in Xano. Here’s how the set of functions, variables, and requests looks. And a clear diagram of Xano’s role in our architecture.

This is what the set of functions looks like: It contains functions, variables and queries:

Scalability and Performance
Xano’s architecture enables it to handle large volumes of requests. As our user count grew, we set up automatic server scaling. During critical load events (like traffic spikes or DDoS), Xano can temporarily scale beyond plan limits.

Xano also allows you to:

Set up database purges by condition (e.g., delete old logs)
Scale storage as needed (SSD customization)
Integrate with external third-party services
For an early-stage SaaS product — this is ideal.

This is an illustration of Xano's interaction points in architecture.

Personal Challanges
At first, I took the “do everything at once” approach: I designed, thought through the logic, and wrote API requests — all in parallel. It was exhausting. Now I work differently:

I design each feature separately
I model the database for it
I connect everything via Wized and APIs

This avoids chaos and allows for easier refactoring. The whole architecture now feels like modular building blocks.

Real-Time Chat
I implemented chat using Ably — a real-time platform that supports sockets, rooms, presence tracking, etc. But since Wized didn’t support WebSockets back then, I had to write JS manually. The design was done in Webflow; the logic — in custom code.

It’s one of the few modules where we stepped outside the no-code paradigm. But overall, the decision paid off. Now I’m considering migrating the chat fully to Wized (since new features have been added).

If you’ve worked with platforms like Ably or others — share your experience in the comments. I’d love to compare different approaches.

Business Value
After launching, we encountered a typical set of bugs and user feedback — but I realized we were on the right track.

Changing the database structure no longer caused painful issues. The system handled decent loads, and when spikes occurred — Xano dynamically scaled resources beyond the base tier. Overall, implementing new features or improving existing functionality wasn’t a problem.

We’ve been able to build the platform while skipping the “monolithic monster” stage.

When our user base grows significantly, we’ll be able to switch to a microservice architecture — which Xano also supports.

For businesses, I believe it’s crucial to implement changes quickly and with minimal bugs.

Architecture Budget

Xano — $100/month
Webflow — $40/month
Wized — $150/month

Total: under $300/month for a full SaaS stack that’s scalable.

Future Outlook
Low-code is no longer just for frontends. It’s a full-fledged alternative to traditional development — for certain types of projects.

You can build a mid-complexity SaaS in two months of full-time work by a single developer. The key is choosing the right stack — and not being afraid to explore new tools.

The market is just beginning, and there aren’t many specialists who can combine these tools.

Thanks for reading to the end! In my next article, I’ll share how I implemented key features like filtering, listings, authentication, security, and more. In the meantime — feel free to drop comments, questions, or just a “+” if you found it useful.

P.S. If you’re a founder thinking about building an MVP — message me, I’ll be happy to help with advice or stack selection.

Forem: Maksym Kunytskyi

So what should we call developers who write regular code? Not a vibe coder, not a low-coder. Maybe an organic developer? <3

The AI “Revolution” Is Still Stuck in a Chatbox

Everyone talks about the “AI revolution.” That interfaces are about to change forever. But it’s 2025, trillions spent, and the only real interface we still have? 👉 A chatbox.

What cookie consent libraries do you use? 🍪 Looking for something easy to integrate, multi-language, customizable, and GDPR-friendly. Do you prefer big tools like Cookiebot/OneTrust or lightweight open-source solutions?

From MVP to Product: How I Built a SaaS App Without Writing a Line of Code

From MVP to Product: How I Built a SaaS App Without Writing a Line of Code

💡 The Idea

🏗 Step 1: Visual Front-End with Webflow

🧠 Step 2: Backend Logic with Xano

📊 Step 3: Admin & Data Layer with Airtable (Optional)

🔄 Step 4: Automation with Zapier / Make

💳 Step 5: Payments & Subscriptions

🔐 User Authentication

📬 Emails and Reports

🧪 Beta Testing & Feedback

📈 Scaling? No Problem

✅ Summary: Stack Overview

🧠 Final Thoughts

How Many Technical Calls Do You Really Need?

What I’ve noticed 👇

So what’s the alternative?

1. ✍️ Better async workflows

2. 🎯 Fewer people in the room

3. ⚙️ Smarter default behaviors

4. 🧭 Push ownership

Not anti-meeting, just anti-waste

What about you?

How Low-Code Databases Are Reshaping the Way We Build Products (And Why I’m Betting on Them)

How Low-Code Databases Are Reshaping the Way We Build Products (And Why I’m Betting on Them)

From Skeptic to Believer: My Journey

Why Low-Code Databases Are (Finally) Worth It

What You Can Actually Build With It

What to Watch Out For

Why It Matters Right Now

TL;DR: My Hot Take

30 Things I Wish I Knew Before I Started Web Development

1. You don’t need to know everything before building.

2. HTML and CSS are more powerful (and complex) than you think.

3. JavaScript will confuse you — that’s normal.

4. You can break production with a missing semicolon.

5. Frameworks change, fundamentals don’t.

6. Understanding the why behind code is more important than copying the how.

7. Tutorials are helpful — until they become a crutch.

8. Being stuck is part of the job.

9. Googling is a skill. Learn it.

10. You don’t have to build the backend from scratch. Use tools.

11. Design matters. Learn at least basic UX/UI.

12. Writing clean code is harder than writing working code.

13. Code comments aren’t for others — they’re for future you.

14. Copying Stack Overflow is fine. Not understanding it is not.

15. Break big problems into tiny ones.

16. Time spent planning saves time debugging.

17. You don’t need a CS degree to be a great dev.

18. Your first portfolio will suck. It’s okay.

19. Debugging is 80% of your time. Embrace it.

20. Learn Git early. And back everything up.

21. You will write bad code. You’ll survive.

22. Don’t overengineer things. MVP is your best friend.

23. Naming things is harder than expected.

24. Soft skills matter more than you think.

25. Talk to real users before you build.

26. Coding is creative work. Don’t burn out.

27. Sleep helps fix bugs. Seriously.

28. Pair programming teaches you a lot — fast.

29. Build real projects. Fake ones don’t stick.

30. You’ll never feel like you “know enough.” Start anyway.

🧠 Over to you!

How we built Microns on a full low-code stack — and launched globally in 6 months

6. **Understanding the why behind code is more important than copying the how.**

13. **Code comments aren’t for others — they’re for future you.**