DEV Community: Ntty

Stop building the 'Perfect' SaaS and start charging for it

Ntty — Sun, 23 Aug 2026 11:00:55 +0000

The Trap of the 'One More Feature'

I spent six months building a project a few years ago that never saw a single user. I had a fully automated CI/CD pipeline, a perfectly normalized database schema, and a custom-built authentication system because I didn't trust the third-party options. I felt like I was making progress because I was writing code every day.

Here is the truth: writing code is not the same as building a business. For most developers, coding is the comfortable part. Marketing, pricing, and talking to strangers are the scary parts. So, we hide in the IDE. We tell ourselves that the product is not ready yet. We think, 'If I just add this one more feature, people will actually pay for it.'

This is a lie. Most of the features you think are essential are actually noise. Your users do not care about your clean architecture or your test coverage. They care about whether your tool solves a specific, painful problem in their day.

The MVP is usually too big

Most developers define a Minimum Viable Product (MVP) as a fully functional version of their final vision. That is not an MVP. An MVP should be the smallest possible thing that provides value.

If you are building a tool to automate reports, you do not need a fancy dashboard with drag-and-drop widgets. You need a script that takes a CSV and emails a PDF. If someone is not willing to pay for the ugly, manual version of your solution, they certainly will not pay for the polished version.

I learned this the hard way. I once spent three weeks building a complex onboarding flow with tooltips and progress bars. When I finally launched, I found out that the users did not even want the main feature of the app. I wasted three weeks polishing a door to a room nobody wanted to enter.

How to actually validate

Validation is not asking your friends if they like your idea. Your friends will lie to you because they like you. Real validation is a transaction.

Here are three ways to validate without spending months on code:

The Manual Bridge: Do the work by hand. If your SaaS is supposed to automate a task, do that task manually for a client. If they pay you for the manual result, you have a business. Now you can write code to automate what you just did.
The Pre-Sale: Create a landing page that describes the value. Put a 'Buy Now' button that leads to a waitlist or a pre-order form. If people click that button, you have a signal.
The concierge approach: Work with one single user. Build exactly what they need, deploy it, and watch them use it. Ignore everyone else until that one person is getting value.

Pricing as a feature

Many devs are terrified of pricing. We want to offer a generous free tier because we want 'growth'. But free users are often the most demanding and the least likely to help you build a sustainable product.

Charging money is a filter. It separates the people who have a real problem from the people who are just curious. When someone pays you, they are giving you a mandate to fix their problem.

Do not start with a complex pricing table. Start with one flat fee. It removes the friction of decision-making for the user and the friction of bookkeeping for you.

The Takeaway

Build the smallest possible version of your idea. Launch it while you are still slightly embarrassed by how simple it is. If it fails, you lost two weeks instead of six months. If it succeeds, you have a roadmap written by your customers, not your assumptions.

Focus on the value, not the stack. If you find yourself spending more time on your build pipeline than on your landing page, you are procrastinating via engineering.

For those building tools that involve waiting for AI responses or long processes, keep the UX simple. A clear indicator like the one at https://waitspin.com is often all you need to keep a user from refreshing the page while your backend works.

Stop Treating AI Editors Like Magic Wands

Ntty — Sat, 22 Aug 2026 11:00:58 +0000

The Honeymoon Phase

I spent the first two weeks with Cursor thinking I had found a cheat code. I was hitting Cmd-K, typing a vague request, and watching the code rewrite itself. It felt like I was managing a junior developer who worked at light speed.

Then the bugs started appearing. Not the obvious syntax errors, but the logic gaps. The AI would change a variable type in one file and forget to update the interface in another. Because I was skimming the diffs instead of reading them, I started shipping regressions that I would have caught in five seconds using a traditional editor.

The Trap of the Diff-Review

When you use an AI editor, the primary activity shifts from writing code to reviewing diffs. This is a dangerous shift if you are not careful.

Reviewing a diff is cognitively different from writing the logic. When you write code, you are building a mental model of the data flow. When you review a diff, you are often just checking if the code looks right. This is where the "hallucination creep" happens. The AI suggests a change that looks elegant, fits the pattern of the project, and passes the initial test, but misses an edge case that only happens in production.

A Better Workflow

To stay in control, I had to change how I interact with the tool. Here is the system I use now to ensure I actually understand what is being added to my repo.

1. The Pseudo-Code Prompt

Instead of asking the AI to "implement the payment logic," I now prompt it with the logic steps I want.

Example: "Create a function that takes the cart object, validates the stock levels via the API, calculates the tax based on the user's state, and returns a final total. Use the existing TaxCalculator class."

By defining the steps, I am still the architect. I am not delegating the thinking, just the typing.

2. Small Atomic Changes

It is tempting to highlight 100 lines of code and ask for a refactor. Do not do this. The larger the change, the more likely the AI is to omit a crucial line of logic or introduce a subtle bug.

I now limit my AI edits to small, atomic chunks. If a feature requires five changes, I do five separate prompts. This makes the diffs manageable and the reverts easy.

3. The "Explain it Back" Rule

Whenever the AI suggests a complex block of logic that I did not explicitly dictate, I ask it to explain why it chose that specific approach. If the explanation sounds generic or doesn't make sense, I delete the code and write it myself. If you cannot explain why a piece of code is there, it does not belong in your codebase.

The Danger of Context Overload

AI editors have access to your entire folder. While this is great for finding where a function is defined, it can lead to "context pollution."

Sometimes the AI sees a deprecated pattern in an old file and decides to replicate that pattern in your new feature because it thinks that is the project style. I have found that manually adding only the relevant files to the context window is far more effective than relying on the automatic index. It forces you to think about the dependencies of the feature you are building.

The Takeaway

AI editors are tools for acceleration, not replacement. The goal is to reduce the friction of boilerplate and repetitive patterns, not to stop thinking about how the software works.

If you spend more time clicking "Accept" than you do reading the actual lines of code, you are creating a technical debt bomb that will explode the first time you have to debug a production outage at 3 AM. Keep the architect in the driver's seat and use the AI as a high-speed typist.

Stop Over-Engineering Your Indie Project

Ntty — Thu, 20 Aug 2026 11:00:22 +0000

I spent three weeks setting up a Kubernetes cluster and a complex event-driven architecture for a project that had exactly zero users. I told myself I was building for scale. In reality, I was just procrastinating on the hard part: building a feature people actually want to use.

When you work as an indie developer, your biggest enemy is not technical debt. It is the lack of a user base. Technical debt only matters if you have a product that survives long enough to be slowed down by it. Most indie projects die long before they hit the scale where a monolithic app becomes a problem.

The Trap of the 'Perfect' Stack

It is easy to get caught up in the hype. You see a thread on X or a blog post about a new framework that promises better type safety or faster build times. You spend a weekend migrating your state management because the new library feels cleaner.

But here is the truth: your users do not care if you use Redux, Zustand, or just a global object. They do not care if your backend is written in Go, Rust, or a basic Node.js script. They care if the button works and if the page loads.

Every hour you spend tweaking your CI/CD pipeline is an hour you are not talking to users or fixing bugs in the core loop of your app. If you are a solo dev, you are the CEO, the product manager, and the janitor. You cannot afford to be a full-time infrastructure engineer too.

Embrace the Boring Stack

The goal for an indie project is to minimize the distance between an idea and a deployed feature. This means choosing tools you already know.

If you know Rails, use Rails. If you know Laravel, use Laravel. If you are comfortable with a simple Express server and a Postgres database, stick with that. Using a tool you have mastered allows you to think about the problem instead of the documentation.

Avoid the temptation to use your indie project as a learning playground for a new language unless the goal of the project is actually learning. If the goal is to ship a product, use the boring stuff. Boring is stable. Boring is fast to write. Boring is easy to debug at 2 AM.

Architecture is a Luxury

In a corporate environment, we are taught to separate concerns, create abstract layers, and build modular services. This is necessary when 50 developers are touching the same codebase. It prevents people from stepping on each others toes.

When you are alone, these abstractions are often just walls you build between yourself and your code.

Do not build a microservices architecture for a CRUD app.
Do not create a complex plugin system before you have a single plugin.
Do not build a generic wrapper for your API calls that handles every possible edge case when you only have three endpoints.

Write the simplest code that solves the problem. If it becomes a mess later, that is a high class problem because it means you have enough users to justify the time it takes to refactor.

The 'Ship It' Checklist

Next time you feel the urge to spend a day refactoring your folder structure or adding a new layer of abstraction, ask yourself these three questions:

Does this change directly improve the user experience?
Will this save me more than an hour of work per week in the long run?
Am I doing this because it is necessary, or because I am afraid to launch?

If the answer to all three is no, stop. Close the IDE and go find a way to get your first ten users.

Concrete Takeaway

Choose a tech stack you already know, build a monolith, and avoid any infrastructure that requires more than ten minutes to set up. Your job is to validate the idea, not to build a masterpiece of software engineering. Ship the ugly version first.

SEO for Developers: Stop Worrying About Keywords and Fix Your Rendering

Ntty — Wed, 19 Aug 2026 11:00:56 +0000

Most developers hate SEO because it feels like voodoo. We are told to "optimize for keywords" or "build backlinks," which sounds like marketing fluff. But there is a side of SEO that is purely engineering. Technical SEO is about making sure a bot can discover, crawl, and render your page without hitting a wall.

If you are building a modern web app with a framework like Next.js, Nuxt, or Remix, you are already halfway there. But there are specific technical traps that can kill your rankings regardless of how good your content is.

The Client-Side Rendering Trap

Google can execute JavaScript, but it does not do it instantly. There is a process called the two-wave index. First, Google crawls the HTML. If your page is just a blank div with an id of "root," the bot sees nothing. It then puts the page in a queue for rendering, which happens later when resources are available.

If your critical content depends on a slow API call that happens in a useEffect hook, you are risking a partial index. The bot might timeout before your data loads.

The Fix: Use Server-Side Rendering (SSR) or Static Site Generation (SSG) for any page you want to rank. If you must use CSR, ensure your meta tags and primary headings are present in the initial HTML payload.

Crawl Budget and the Zombie Page Problem

Search engines do not spend infinite time on your site. They have a "crawl budget." If you have 10,000 pages of low-quality, auto-generated content (like filter combinations on an e-commerce site), the bot wastes its budget on those instead of your high-value pages.

I once worked on a project where we had thousands of duplicate pages because of trailing slashes and inconsistent casing in URLs. The bot was crawling the same page four different times.

The Fix:

Implement canonical tags. Tell the bot: "Even if you found this via a weird URL, this is the official version."
Use a robots.txt file to block paths that provide no value, like /admin or /search-results.
Set proper HTTP status codes. A 404 should be a 404, not a 200 OK page that says "Not Found."

Core Web Vitals: The Performance Metric

Google now uses actual user experience metrics as a ranking factor. The most frustrating one for developers is usually Cumulative Layout Shift (CLS).

CLS happens when a user starts reading a paragraph, and then an image or an ad loads, pushing the text down. It is a jarring experience, and Google penalizes it.

The Fix:

Always define width and height attributes on images.
Reserve space for dynamic elements using skeleton screens or min-height CSS.
Avoid inserting content above existing content unless it is in response to a user action.

The Metadata Basics

You do not need to be a copywriter to handle metadata. You just need a system.

Every page needs a unique title tag and a meta description. If you are building a dynamic site, create a helper function that generates these based on your data. For example, if it is a product page, the title should be "Product Name | Site Name."

Do not forget the Open Graph (OG) tags. While these do not directly affect Google rankings, they affect how your links look on social media, which drives the traffic that leads to backlinks.

The Concrete Takeaway

Stop treating SEO as a marketing task. Treat it as a performance and accessibility task.

If you want your site to rank, focus on this checklist:

Is the main content in the initial HTML source? (View Source to check).
Do all images have dimensions to prevent layout shift?
Are you using canonical tags to prevent duplicate content?
Does every page return a proper 200, 404, or 301 status code?

When you fix the technical foundation, the marketing team's keyword strategy actually has a chance to work.

Vibe Coding: Why Natural Language is the New Compiler

Ntty — Tue, 18 Aug 2026 11:00:53 +0000

The Shift to Intent-First Development

For years, the barrier to building software was syntax. You had to know exactly where the semicolon went or how the specific framework handled state. Now, we are entering an era of "vibe coding." It sounds fluffy, but it is actually a shift toward intent-first development.

In this mode, the developer focuses on the high-level logic, the user flow, and the architecture, while the LLM handles the boilerplate and the API specifics. You are no longer typing every character. You are describing a state, reviewing the output, and iterating based on the result.

The Danger of the Magic Button

When you start building via prompts, it is easy to fall into the trap of blind acceptance. You prompt for a feature, the AI spits out 100 lines of code, it works on the first try, and you hit merge.

This is where most developers mess up. If you do not understand the code the AI wrote, you are not the lead developer anymore. You are a passenger. The moment a bug appears in production, you will be staring at a codebase you did not actually write, trying to debug logic you never conceptualized.

How to Vibe Code Without Breaking Things

To make this work, you need a specific workflow. You cannot just "vibe" and hope for the best. You need a feedback loop that keeps you in control.

1. The Pseudo-Code Bridge

Do not go straight from a vague idea to a prompt. Write a brief technical spec in plain text first.

Instead of saying "Make a login page," say "Create a login component using Tailwind. It needs a validation check for email format, a loading state for the submit button, and it should call the /auth/login endpoint."

By defining the requirements, you are setting the boundaries. The AI provides the implementation, but you provided the architecture.

2. Atomic Iteration

Avoid the "mega-prompt." If you ask an AI to build a whole dashboard in one go, you will get a generic, buggy mess.

Build in tiny increments. Ask for the data model. Then the API route. Then the basic UI. Then the styling. Then the error handling. This allows you to verify the code at every step. If the AI goes off the rails, you only have to revert five lines of code, not five hundred.

3. The "Explain it Back" Rule

If the AI generates a complex regex or a weird useEffect hook that you do not immediately understand, stop. Ask it: "Why did you choose this approach over X?"

If the explanation is vague, the code is probably a hallucination or a suboptimal pattern. Force the AI to justify its architectural choices. This turns the tool from a code generator into a pair programmer.

The New Skillset

Being a great developer in this environment is less about memorizing documentation and more about system design. You need to know how a database should be structured, how caching works, and how to secure an endpoint.

If you do not know the fundamentals, vibe coding will lead you into a wall. But if you do know them, you can build things ten times faster because you are no longer bogged down by the friction of syntax.

The Concrete Takeaway

Stop treating AI as a magic box that writes your app. Treat it as a junior developer who is incredibly fast but occasionally lies.

Your job has shifted from writing code to reviewing code and defining intent. The win is not in how fast you can generate a feature, but in how well you can maintain the system after it is generated. Keep your prompts specific, your iterations small, and your skepticism high.

Stop Over-Engineering Your State Management

Ntty — Mon, 17 Aug 2026 11:00:20 +0000

I spent three years of my career reaching for Redux or Zustand the moment a project felt "medium sized." I thought that was what professional developers did. I would set up slices, actions, and complex store configurations before I even had a working UI.

Most of the time, I was solving a problem that did not exist. I was managing server cache in a global store, which led to bugs where the UI showed stale data because I forgot to trigger a fetch on a specific page transition.

The State Confusion

The biggest mistake we make is treating all state as the same. State is not just one big bucket of data. It falls into three distinct categories:

UI State: Is this sidebar open? Which tab is active? This belongs in the local component.
Server Cache: What is the user's profile name? What are the items in the cart? This is just a local copy of data that lives in a database.
Global App State: The current authenticated user or a preferred theme. This is actually very small.

When we put Server Cache into a global store, we create a synchronization nightmare. We end up writing a dozen lines of boilerplate just to update a single string in a database.

The Simple Hierarchy

Instead of jumping to a library, try this hierarchy of decision making.

First, keep it in the component. If only one or two components need the data, use local state. If you are passing props down three levels, that is a smell, but it is often better to just pass the props than to introduce a global store that makes the component non-portable.

Second, use a dedicated server state tool. If you are using React, tools like TanStack Query handle caching, loading states, and re-fetching automatically. They remove the need to store the results of an API call in a global store. The tool becomes the cache, and your components just hook into the data they need.

Third, use Context or a small store for truly global data. Your theme or user session does not change every second. Using a simple provider for this is enough.

A Real Example of Over-Engineering

I once saw a project where the developer used a global store to track the value of a search input field. Every single keystroke triggered a global action, which updated the store, which re-rendered half the application.

It was a disaster for performance. The fix was simple: move the input value to a local useState hook and only trigger the search function when the user hits enter or after a debounce period.

We often confuse "centralized" with "organized." Centralizing everything in one store does not make it organized. It just makes it a single point of failure that is hard to debug.

How to Audit Your Current Project

If you feel your state management is getting bloated, do this audit:

Look at your global store. For every piece of data, ask: "Does this come from an API?" If yes, move it to a server state manager.
Ask: "Is this used in more than two distant branches of the component tree?" If no, move it to local state or lift it up one level.
Ask: "Does this data need to persist across page refreshes?" If yes, it belongs in a cookie or localStorage, not just a JS variable.

The Takeaway

Complexity is a cost. Every line of boilerplate you write is a line you have to maintain. Start with the simplest possible way to move data. Use local state first, server state tools second, and global stores only as a last resort. Your bundle size will be smaller, and your brain will be less stressed.

Stop treating LLMs like a database

Ntty — Sun, 16 Aug 2026 11:00:55 +0000

I spent three weeks building a feature that relied on an LLM to return structured data about a specific set of API endpoints. During testing, it worked perfectly. In production, it started hallucinating fields that did not exist, and the whole frontend crashed because the JSON was malformed.

My mistake was treating the model like a database. I expected it to recall specific facts and return them in a strict format every single time. That is not how these models work. They are probability engines, not lookup tables.

The Probability Trap

When you ask an LLM for a specific fact, it is not querying a disk. It is predicting the next most likely token based on weights. If the prompt is slightly different, or if the model version updates, that probability shifts.

If your application logic depends on the AI always remembering that "User ID is a UUID v4", you are building on sand. The model might get it right 99 times, but the 100th time it will return a string like "The User ID is a UUID v4: 123-abc" and your JSON.parse() call will explode.

The Pattern: Separation of Knowledge and Reasoning

To make AI features stable, you have to separate the knowledge (the facts) from the reasoning (the processing).

Instead of asking the AI to remember your business rules, feed those rules into the prompt as context. This is the core idea behind RAG, but you do not always need a complex vector database to do it. Sometimes a simple system prompt with a list of constants is enough.

Here is how I restructured my approach:

Externalize the Truth: Put all factual data in a JSON file or a database.
Inject Context: Fetch the necessary data and inject it into the prompt. Tell the AI: "Using only the following data, perform X task."
Schema Enforcement: Stop hoping for valid JSON. Use a library that enforces a schema (like Zod in TypeScript) to validate the output before it ever touches your application state.

Handling the "Creative" Drift

Even with a strict schema, models drift. I noticed that as I added more context to my prompts, the AI started ignoring the middle section of the instructions. This is a known issue called "lost in the middle."

To fix this, I started using a technique called few-shot prompting. Instead of telling the AI "Return a list of errors", I gave it three concrete examples of a request and the exact expected response.

Example:

Input: "The server is down"
Output: { "category": "infrastructure", "severity": "high" }

Input: "I forgot my password"
Output: { "category": "user-auth", "severity": "low" }

This anchors the model. It stops guessing the format and starts mimicking the pattern.

Testing for Non-Determinism

Unit tests for AI are different. You cannot test for equality because the output changes. I started implementing "LLM-based evaluation".

I wrote a separate, more powerful model (like GPT-4) to act as a judge for my smaller, faster production model. The judge model does not check if the strings match. It checks if the intent and the facts are correct based on a rubric.

If the production model says "The price is 10 dollars" and the judge knows the price is 10.00, it passes. If it says "The price is 12 dollars", it fails. This is the only way to scale AI features without manually reading a thousand logs a day.

The Concrete Takeaway

If your code breaks because the AI forgot a detail or changed a word, your architecture is the problem, not the model.

Move your facts out of the model weights and into your code. Use the LLM for the transformation and reasoning, but keep the source of truth in a place where you can actually version control it. Treat the AI as a flaky intern: give them clear instructions, provide examples, and always double check their work with a validator.

Stop Using AI to Write Code, Start Using It to Navigate

Ntty — Sat, 15 Aug 2026 11:00:56 +0000

The trap of the 'Generate' button

When I first started using AI-powered editors like Cursor, I fell into the same trap as everyone else. I would write a prompt, hit generate, and watch a wall of code appear. It felt like a superpower. For the first hour, productivity spiked. By the end of the week, I was spending more time debugging subtle hallucinations than I would have spent writing the code from scratch.

The problem is that AI is great at syntax but often blind to the architecture of your specific project. It suggests a library you are not using or creates a function that ignores a critical edge case in your data model. When you let the AI drive, you stop thinking about the 'why' and start focusing on 'does this run'.

Shifting to AI-assisted navigation

I changed my approach. Instead of asking the AI to write the feature, I started using it to navigate the codebase. This is where the real value lies.

In a large project, the hardest part is not writing the logic. It is finding where that logic should live. I now use the AI to ask questions like:

"Where is the logic that handles user session timeouts?"
"Which components are currently consuming the AuthProvider?"
"If I change the schema of the User table, which services will break?"

By using the AI as a high-speed index for my own code, I stay in control of the architecture. I find the right file, I understand the context, and then I write the actual implementation. The AI helps me get to the starting line faster, but it does not run the race for me.

The 'Review-First' workflow

If you do use the AI to generate a snippet, you have to change how you review it. Most developers accept a diff if it looks correct at a glance. That is a mistake.

I now treat AI-generated code as if it were written by a junior developer who is very confident but occasionally lies. My review process looks like this:

Check for imports: Did it import a package I do not have?
Trace the data flow: Where did this variable come from? Is it actually defined in the scope?
Search for 'magic' logic: Did it invent a method that does not exist on the object?

When you stop trusting the output blindly, you start noticing the patterns the AI uses. You realize it often over-engineers simple tasks. By manually refining the AI's output, you keep the codebase clean and maintainable.

Better prompts for better context

To make this work, you need to give the AI the right context. Generic prompts get generic results. Instead of saying "Fix this bug", I started being specific about the constraints.

I use prompts like:

"Refactor this function to reduce complexity, but do not add any new dependencies and keep the return type as a Promise."

Giving the AI a set of boundaries prevents it from taking wild guesses. It forces the tool to work within the existing patterns of your project rather than trying to rewrite your style to match its training data.

The concrete takeaway

AI editors are not replacement for thinking. They are the world's best grep tool.

Stop using the AI to generate 50 lines of code at once. Instead, use it to locate the exact line that needs to change, understand the surrounding context, and then write the fix yourself. You will spend less time fixing 'AI bugs' and more time actually building features. The goal is to reduce the distance between an idea and the implementation, not to outsource the implementation entirely.

Stop building features and start building 'Waiting States'

Ntty — Fri, 14 Aug 2026 11:00:58 +0000

The AI Latency Problem

Most of us building AI tools right now are obsessed with tokens per second. We spend hours tweaking prompts and swapping models to shave two seconds off a response. But here is the reality: users are used to waiting. Whether it is a LLM generating a long report or a codebase being indexed, there is always a gap.

Most developers treat this gap as a bug. We throw a generic loading spinner on the screen and hope the user does not refresh the page. This is a waste of prime real estate. In a traditional app, a loading state is a failure of performance. In an AI app, the loading state is a core part of the user experience.

The Psychology of the Wait

There is a huge difference between 'unoccupied time' and 'occupied time'. If a user stares at a blank screen for five seconds, it feels like twenty. If that same user is reading a relevant tip, seeing a progress bar that actually moves, or getting a preview of what is happening, the perceived wait time drops significantly.

When I started building my first few AI-integrated tools, I ignored the loading states. I focused on the output. I noticed my churn rate was high not because the output was bad, but because users felt the app was 'hanging'. They did not trust the process because I gave them zero feedback during the latency window.

Turning Friction into Value

You can use these wait-states to solve actual business problems. Instead of a spinner, try these patterns:

Educational Onboarding: Use the 3-5 second gap to show a 'Did you know?' tip about a feature the user has not tried yet. This is a natural way to increase feature adoption without annoying pop-ups.
Transparency Logs: Show the AI's 'thought process'. Instead of 'Loading...', show 'Searching documentation...', then 'Analyzing context...', then 'Drafting response...'. This builds trust in the result.
Micro-Upsells: If a user is on a free tier, the wait-state is the perfect place to mention that a Pro plan reduces latency or allows for faster models.

The Technical Implementation

Do not hardcode your loading messages. If you do, you will end up with a mess of if-else statements. Create a simple queue of messages or a state machine that cycles through a list of strings based on the current step of your backend pipeline.

If you are using React or Vue, build a dedicated WaitState component that accepts a type prop. This allows you to switch from a 'generic' wait to a 'processing' wait without rewriting your UI logic every time you add a new API call.

The Monetization Angle

If you are building a B2B tool, your 'wait-state' is actually a place to demonstrate value. For example, if your tool optimizes code, show a live counter of 'Potential bugs being checked' during the wait. You are not just making them wait; you are proving that the tool is working hard for them. This justifies your pricing.

When developers treat the latency as a product feature rather than a technical debt, the entire feel of the app changes. You stop fighting the model speed and start managing the user's attention.

Concrete Takeaway

Audit your app today. Find every place where a user sees a spinner for more than two seconds. Replace that spinner with either a progress update, a feature tip, or a transparency log. Stop treating the gap as a void and start treating it as a communication channel.

If you want a cleaner way to handle these transitions, check out https://waitspin.com for some inspiration on better loading experiences.

Stop Over-Engineering Your State Management

Ntty — Thu, 13 Aug 2026 11:00:56 +0000

The Trap of the Global Store

I spent three years of my career thinking that every single piece of data in a web application needed to live in a global store. Whether it was a user profile or whether a dropdown menu was open, it all went into Redux or Vuex. I thought I was being organized. In reality, I was creating a maintenance nightmare.

When you put everything in a global store, you create invisible dependencies. You change a value in one place, and a component three levels deep in a different branch of the UI tree re-renders for no reason. You end up spending more time debugging the state flow than actually building features.

The State Hierarchy Rule

To avoid this, I started following a simple rule: keep state as close to where it is used as possible.

1. Local Component State

If a piece of data is only used by one component (or its immediate child), use local state. This includes toggle switches, form input values before submission, and hover states. If you move a 'isModalOpen' boolean to a global store, you have to remember to manually reset it when the component unmounts, or the modal will pop up unexpectedly the next time the user visits that page.

2. Lifted State

If two sibling components need the same data, lift the state to their common parent. Pass the data down via props and pass a callback function to update it. It feels like 'prop drilling' at first, but for 2 or 3 levels, it is far more explicit and easier to trace than a global dispatcher.

3. Context or Provider Pattern

Use this for truly global data that rarely changes. Think of themes (dark/light mode), authenticated user info, or localization settings. Context is great for avoiding prop drilling, but it is not a replacement for a state management library because it is not optimized for high-frequency updates. If you put a fast-changing timer in a Context provider, you will likely trigger a re-render of your entire app every second.

4. External State Libraries

Only reach for a dedicated store (Zustand, Redux, Pinia) when you have complex data dependencies. For example, a collaborative text editor or a complex dashboard where an action in the sidebar must instantly update a chart in the main view and a notification in the header.

Dealing with Server State

One of the biggest mistakes I made was treating server data (API responses) the same as UI state.

Storing API data in a global store usually leads to 'stale data' bugs. You fetch a user list, store it in Redux, and then update a user on the server. Now your global store is out of sync.

Instead, use a caching layer or a data-fetching hook. Let a dedicated tool handle the loading states, error handling, and cache invalidation. Your global store should only hold the minimal amount of data needed to coordinate the UI, not a mirror of your entire database.

The 'Delete' Test

Whenever I am tempted to add a new slice to a global store, I ask myself: 'If I deleted this component, would any other part of the app break?'

If the answer is no, the state belongs in the component. If the answer is yes, I check if it can be handled by a simple Provider. If it is still too complex, only then does it go into the global store.

Concrete Takeaway

Stop starting your projects with a global store by default. Start with local state. Lift it up when it becomes painful. Move it to a Provider when it becomes repetitive. Only implement a full state management library when you can point to a specific, complex data flow that cannot be solved with the built-in tools of your framework.

Less code in your store means fewer bugs and a faster app.

SEO for Developers: Stop obsessing over keywords and fix your Core Web Vitals

Ntty — Wed, 12 Aug 2026 11:00:35 +0000

Most developers hate SEO because it feels like magic or marketing fluff. We get told to "add more keywords" or "get more backlinks," which are tasks for content writers and PR people. But there is a massive technical side to SEO that is entirely within our control.

If your site is slow, has layout shifts, or uses a div for everything, no amount of keyword stuffing will save your rankings. Google cares about user experience. Here is how to handle the technical side of SEO without becoming a marketing expert.

The Layout Shift Nightmare

Cumulative Layout Shift (CLS) is one of the most frustrating metrics for users and a signal for search engines. You know when you are about to click a button, but an image finally loads, the page jumps, and you click an ad instead? That is a CLS failure.

To fix this, stop letting the browser guess the size of your elements. Always define width and height attributes on images. If you are using responsive images with width: 100%, use the aspect-ratio CSS property. This reserves the space before the asset downloads, keeping the page stable.

Semantic HTML is not optional

I see too many modern apps that are just a sea of <div> and <span> tags. While the browser can render this, search engine crawlers struggle to understand the hierarchy of your information.

Use the correct tags. A <main> tag tells the crawler where the primary content lives. An <article> tag defines a self contained piece of content. Use <h1> through <h6> in a logical order. Never use an <h3> just because you like the font size; use CSS for styling and HTML for meaning. When you use a <nav> tag, the crawler knows exactly where your site navigation is, which helps it index your internal links more efficiently.

The Client-Side Rendering Trap

If you are building a heavy Single Page App (SPA) with React, Vue, or Angular, you might be killing your SEO. While Google can execute JavaScript, it is not as reliable or fast as parsing static HTML. Some crawlers give up if the content takes too long to render.

If your content is dynamic but needs to be indexed, move to Server-Side Rendering (SSR) or Static Site Generation (SSG). This ensures that when a bot hits your URL, it receives a fully formed HTML document. If you cannot move away from a pure CSR architecture, look into pre-rendering tools that generate static versions of your pages during the build process.

Metadata and Social Graph

Your <title> and <meta name="description"> tags are the primary way your site appears in search results. If you leave these blank or use a generic "Home Page" title, your click-through rate will plummet.

Beyond basic SEO, implement Open Graph (og:) and Twitter Card tags. These do not directly boost your rank, but they control how your links look when shared on social media. A link with a proper image and a concise summary gets more clicks, which leads to more traffic, which indirectly signals to search engines that your content is valuable.

The robots.txt and Sitemap Duo

Do not let search engines waste their "crawl budget" on pages that do not matter. Your /admin panel, your /search results pages, and your /thank-you pages should not be indexed.

Use a robots.txt file to tell bots where they are not allowed to go. Pair this with a sitemap.xml file. A sitemap is essentially a map of your site that tells the crawler, "Here are the 50 pages I actually care about." This ensures that new content is found and indexed much faster than waiting for the crawler to find a link to it.

Concrete Takeaway

Stop thinking of SEO as a marketing task. Treat it as a performance and accessibility task. If you focus on fast load times, zero layout shift, and semantic HTML, you are doing 80 percent of the technical work. The rest is just writing good content.

Stop writing prompts and start building agentic content loops

Ntty — Tue, 11 Aug 2026 11:00:53 +0000

The prompt engineering trap

Most developers start with a single prompt. You tell an LLM to "write a technical guide about X," you get a generic result, and then you spend an hour manually editing the hallucinations. This is not a workflow. It is just a faster way to get a bad first draft.

When I first tried to automate my technical blog, I thought the solution was a longer prompt. I spent days perfecting a 500 word system instruction. It still failed because the LLM cannot verify its own claims in a single pass. It just predicts the next token.

To get production-ready content, you need to move from a linear prompt to an agentic loop. This means breaking the task into roles: a researcher, a writer, and a critic.

The Architecture of a Content Loop

An agentic workflow treats content as a state machine. Instead of one big call, you chain several small, specialized calls that check each other's work.

1. The Research Agent

This agent does not write. Its only job is to find facts. Give it access to your codebase or a set of documentation URLs. Ask it to produce a structured JSON object of key technical constraints, API endpoints, and edge cases. If it cannot find a specific fact, it must flag it as "missing" rather than guessing.

2. The Draft Agent

This agent takes the JSON from the researcher and turns it into prose. Because the facts are already locked in, the writer cannot hallucinate as easily. The goal here is structure and flow, not accuracy. Accuracy was handled in the previous step.

3. The Critic Agent (The Most Important Part)

This is where the magic happens. The critic agent is given the original research data and the draft. Its prompt is simple: "Find three things in this draft that contradict the research or sound like marketing fluff."

If the critic finds errors, the draft is sent back to the writer with the feedback. This loop continues until the critic gives a thumbs up. This is a self-correcting system.

Implementing this with Code

You do not need a heavy framework to start. A few Python scripts or a Node.js loop will work. The key is the data hand-off.

Research Phase: Output a Markdown list of facts.
Draft Phase: Use those facts as context blocks.
Review Phase: Use a boolean check (Pass/Fail). If Fail, loop back to Draft.

One common mistake is letting the agent decide when it is finished. Agents are too polite. They will say "This looks great!" just to end the task. You need to force the critic to be pedantic. Tell it that its only reward is finding mistakes.

Scaling to GEO (Generative Engine Optimization)

We are moving from a world of SEO to GEO. People are not just clicking links; they are asking Perplexity or ChatGPT for a summary of a solution. These engines prioritize cited, factual, and structured data.

To optimize for this, your agentic loop should specifically target "cite-able" moments. Instead of saying "Our API is fast," the agent should be forced to say "Our API responds in 40ms as shown in the benchmark tests."

When you provide concrete data and clear citations, LLMs are more likely to pick up your content as a primary source for their users. This is how you win in the age of AI search.

Concrete Takeaway

Stop trying to find the perfect prompt. Instead, build a pipeline: Research -> Draft -> Critic -> Refine. By separating the factual research from the creative writing, you eliminate 80% of hallucinations and create content that actually helps developers.

I use Citedy (https://www.citedy.com) to help manage the sourcing and citation side of this process, ensuring the facts stay grounded.

Build the loop, not the prompt.