That asymmetry is the whole argument for client-side validation. A check that costs 5ms in the browser can save a minute of GPU time and a refund. Here are the five we run on Stivio before a job is ever queued, and the reasoning behind each.

1. Format, before anything else

We accept PNG, JPEG and WebP. Not because the models are picky about containers, but because everything downstream — thumbnailing, EXIF reads, dimension probing — assumes a decodable raster.

const ACCEPTED = ['image/png', 'image/jpeg', 'image/webp']

function checkFormat(file) {
  if (!ACCEPTED.includes(file.type)) {
    return { ok: false, reason: 'format' }
  }
  return { ok: true }
}

One caveat: file.type comes from the OS, not from the bytes. A renamed .txt will happily report image/png. If that matters to you, read the first 12 bytes and check the magic number. We do the cheap check in the browser and the real one server-side, because the browser check is about user feedback speed, not security.

2. Size, with a number the user can act on

The limit is 10 MB. What matters more than the number is the error message. "File too large" is useless. "This photo is 24 MB, the limit is 10 MB — try exporting at a smaller size" tells someone what to do next.

Modern phone cameras produce 3–8 MB files, so the limit almost never bites for real photos. The uploads that hit it are usually screenshots of screenshots, or PNG exports of photographs — which brings us to the next check.

3. Aspect ratio, because the output inherits it

This is the one most people miss. The generated video keeps the aspect ratio of the source image. There is no crop step, no letterbox. So the framing decision is made at upload time, not at export time.

function readDimensions(file) {
  return new Promise((resolve, reject) => {
    const img = new Image()
    const url = URL.createObjectURL(file)
    img.onload = () => {
      URL.revokeObjectURL(url)
      resolve({ w: img.naturalWidth, h: img.naturalHeight })
    }
    img.onerror = () => { URL.revokeObjectURL(url); reject() }
    img.src = url
  })
}

Two things worth knowing here. URL.revokeObjectURL is not optional — without it, every rejected upload leaks a blob for the lifetime of the tab. And naturalWidth is the decoded pixel width, which is what you want; width reflects CSS layout and will lie to you if the image is in the DOM.

Once you have the ratio, you can tell the user where the output will fit:

const RATIOS = [
  { name: '9:16 (Reels, TikTok)', value: 9 / 16 },
  { name: '1:1 (product grid)',   value: 1 },
  { name: '16:9 (YouTube, web)',  value: 16 / 9 },
]

function nearestTarget(w, h) {
  const r = w / h
  return RATIOS.reduce((best, t) =>
    Math.abs(t.value - r) < Math.abs(best.value - r) ? t : best
  )
}

Telling someone "this will render as 4:3, closest to 1:1 — crop it first if you want a Reel" before they spend credits is worth more than any amount of post-hoc support.

4. Minimum dimensions, because upscaling shows

A 200x200 avatar technically passes every check above. It also produces an unusably soft video, because the model animates what it was given. We warn below roughly 512px on the short edge. Not a hard block — someone may genuinely want to animate a small image — but a warning that sets expectations.

The general principle: block what will fail, warn what will disappoint. Conflating the two produces either a tool that feels obstructive or one that wastes people's money.

5. EXIF orientation, the silent one

JPEGs from phones carry an orientation flag. Browsers respect it when rendering an <img>; many server-side decoders do not. The result is the classic bug where the preview looks upright and the output is rotated 90 degrees.

The fix is to normalise before upload — draw to a canvas, which bakes in the display orientation, and send the canvas output instead of the original bytes:

async function normalise(file) {
  const bitmap = await createImageBitmap(file, { imageOrientation: 'from-image' })
  const canvas = document.createElement('canvas')
  canvas.width = bitmap.width
  canvas.height = bitmap.height
  canvas.getContext('2d').drawImage(bitmap, 0, 0)
  return new Promise(res => canvas.toBlob(res, 'image/jpeg', 0.92))
}

createImageBitmap with imageOrientation: 'from-image' does the rotation for you. Note that this strips all EXIF, including the orientation tag — which is exactly what you want, since the pixels are now already in the right order.

The part that isn't a check

None of this validates the prompt, which is where most disappointing outputs actually come from. A sharp, correctly-oriented, well-framed photo with the instruction "make it cool" will still produce something arbitrary.

We ended up putting three labelled fields in front of people instead of one free-text box — what moves, how the camera behaves, the mood — because splitting the question is the cheapest way to get a specific answer. That change did more for output quality than any of the five checks above.

But the checks are still worth having. They are the difference between a user who wasted two minutes and a user who wasted two minutes and some credits.

I write a small engineering blog. Nothing huge, around 2,400 monthly readers, mostly developers who land on my posts about message queues and caching layers from a Google search. The writing comes easy to me. The diagrams never did.

The part nobody warns you about

My setup was the usual one. I'd open draw.io in one tab, keep my notes in another, and start dragging rectangles around a canvas. A simple three-service diagram with a load balancer, two app servers, and a Postgres instance would take me 40 to 50 minutes. Not because the architecture was complex, but because I'm not a designer. I'd spend ten minutes just trying to make the arrows line up so they didn't cross each other like spaghetti.

The post I remember most clearly was one I published on November 14th about event-driven systems. I'd written the whole thing in about two hours on a Saturday morning at a coffee shop near my apartment in Lisbon, the one on Rua da Prata that does a decent flat white. The writing was done by 11am. The diagram took me until almost 2pm. Three hours for one picture of a Kafka topic feeding three consumers. I closed my laptop genuinely annoyed at myself.

And here's the thing that really got to me: my diagrams looked like everyone else's. The same gray boxes, the same blue cylinders for databases, the same stock AWS icons that show up in roughly half the infrastructure posts on the internet. Readers would scroll past them. I could tell from my analytics that the diagrams weren't where people stopped. They stopped on the code blocks.

The accidental fix

I wasn't looking for a tool. I found it because a friend in my old Berlin meetup group, Marek, dropped a link in our group chat with the message "this saved my last three posts." It was Architecture Diagram AI, and honestly I almost ignored it because I assumed it would be another generic diagram-maker with a free tier that does nothing.

I tried it the next morning. The pitch is simple enough that I was skeptical: you describe the architecture in plain text, pick a visual style, and it generates an actual image. So I typed in something like "a load balancer routing to two Node servers, both talking to a shared Redis cache and a Postgres database." I picked a style that matched the blue-and-orange palette I use on my blog. About fifteen seconds later I had a PNG.

It wasn't the gray-box thing. It was a clean, genuinely good-looking visual that looked like something a design team would have made, not a tired developer at 1am. The first time it generated something usable, I actually said "oh" out loud in my empty kitchen.

What changed in the numbers

I'm a numbers person, so I tracked this. Over the next two weeks I published four posts, and I used the AI architecture diagram generator for the visuals in all of them. My average time-per-diagram dropped from roughly 45 minutes to under 5. That's not a rounding error. Across those four posts, that's something like two and a half hours I got back, which for someone who blogs around their actual job is a real amount of time.

The part I didn't expect was the engagement shift. My average time-on-page went from about 2 minutes 50 seconds to 3 minutes 40 seconds over that stretch. Correlation isn't causation and I'm not going to pretend four posts is a real sample size, but the diagrams stopped being the thing people skipped. One reader even emailed me to ask what tool I used for "the graphics," which had literally never happened in two years of blogging.

The workflow that stuck for me is boring in a good way. I write the post first, all of it. Then I read back through and wherever I think "a picture would help here," I describe the system in one sentence, generate the image, download the PNG, and drop it straight into my CMS. No exporting, no fiddling with SVG settings, no fighting with arrow alignment. The download is a clean PNG that just works wherever I paste it.

A small thing that mattered more than I expected

There's a detail I keep coming back to. Before this, the diagram step had a way of derailing my whole publishing rhythm. I'd finish writing on a Saturday, hit the diagram wall, get frustrated, and tell myself I'd "just do the picture tomorrow." Tomorrow would become next weekend. I had three finished drafts sitting unpublished in October purely because I didn't have the energy to make their diagrams. Two of them I never published at all.

When the diagram stopped being a two-hour chore and became a two-minute one, that backlog problem just evaporated. In December I published six posts, which is more than I'd managed in the previous two months combined. The tool didn't make me a better writer. It removed the specific bit of friction that was quietly killing my consistency, and consistency is most of what blogging actually rewards.

The honest caveats

It's not magic. For one genuinely weird microservices setup with about eleven services and a couple of circular dependencies, I still ended up sketching it by hand because I couldn't describe it cleanly in text. If you can't write the architecture in a sentence or two, you're going to struggle to generate it. And the styles, while good, are styles, so if your blog has a very specific brand look you might find the match isn't perfect every time.

But for the 90% of diagrams I actually make, the ones with a handful of boxes and some arrows showing how data flows, it's replaced my entire old process. I haven't opened draw.io in over a month.

Would I recommend it?

If you write technical content and you've ever felt that specific dread of finishing the words only to face the diagram, yes. I went in skeptical and I'm the kind of person who churns through tools and abandons them after a week. This one stuck. You can try it yourself at architecturediagramai.com — you get a free diagram after signing in with Google, which is exactly how I tested whether it was real before I trusted it with a published post.

I still write at that same coffee shop on Rua da Prata most Saturdays. The flat white is still good. The difference is I'm out the door by noon now instead of fighting arrows until the afternoon.

My sister had just bought her first apartment and asked me — the "tech guy" in the family — to help her visualize moving some walls. She sent me a phone photo of the listing's floor plan, half-blurry, slightly rotated, and asked if I could just "drag the walls around" for her. I assumed there would be a quick web tool for this. There wasn't. At least not one that didn't require an account, a tutorial, and roughly forty minutes of frustration before producing anything useful.

So I did what I always do. I opened a blank repo, made a coffee, and started typing.

Figuring Out What "Reading" a Floor Plan Even Means

The first wall I hit (pun intended) was that floor plans are deceptively hard for computers. Humans look at one and instantly see: this is a wall, this is a door swinging this way, this is a window, that little arc is a toilet. A model just sees a bunch of black lines on a white background.

I spent the first week just collecting samples — old apartment listings, blueprints I'd saved for various reasons, hand-drawn sketches from a Reddit thread — and trying to figure out what consistent visual patterns existed across all of them. The answer, frustratingly, was "not many." Different drafters use different conventions. Some plans label rooms, some don't. Some are to scale, some are vibes.

I ended up building a small pipeline that did three things in sequence: detect the outer boundary of the plan, segment the interior into rooms, and then classify the symbols inside each room. None of these steps were novel on their own — there's plenty of academic work on each piece — but stitching them together so the output was useful to a non-technical person turned out to be the actual hard part.

The Embarrassing First Demo

The first version I showed my sister was, in her exact words, "kind of horrible." It correctly identified the walls but thought her bathtub was a sofa. It missed two doors entirely. It rotated the plan 90 degrees for reasons I still don't fully understand.

But — and this is the part that kept me going — it got the rooms right. The living room was the living room. The kitchen was the kitchen. That meant the underlying segmentation was working; I just had bad symbol recognition on top of it.

I retrained the symbol classifier on a much bigger dataset, added a step that re-orients the plan based on detected text labels, and gave it the ability to ask the user to confirm ambiguous detections instead of just guessing. That last bit alone improved the perceived quality enormously. People are way more forgiving when a tool says "I think this is a door — yes or no?" than when it silently gets it wrong.

Where the Project Stopped Being a Toy

Around week three, I realized the tool was actually useful for something my sister hadn't even asked about: redesign. Once the plan was parsed into structured data — rooms, walls, doors, fixtures — I could let her drag things around, add new walls, swap fixtures, and re-render the result in seconds. I added a simple 3D preview because I wanted to see if it was possible, and it turned out to be the feature she used the most.

She walked her partner through their potential renovation on a video call by sharing the 3D view. He spotted that the new kitchen island would block the only path to the balcony. They changed the plan. I never would have caught that on a 2D drawing, and neither would they.

That was the moment the project stopped feeling like a tech demo and started feeling like a product.

The Boring Stuff That Took Forever

People always ask me what the hard part of a side project is, and the honest answer is never the part you'd expect. For this one, it wasn't the ML. It was:

• File uploads. Specifically, handling the wild variety of formats people throw at a floor plan tool. JPEGs from phones. PDFs scanned at strange angles. Screenshots from listing sites with watermarks. I spent an embarrassing amount of time on a preprocessing step that just tries to find the actual plan inside a noisy image.
• Units. Some plans are in meters, some in feet, some in pixels with no scale reference at all. Letting the user click two points and enter a known dimension to set the scale ended up being one of the most-used features.
• Export. Nobody wants a plan trapped in a web app. Getting clean PNG, PDF, and a basic DXF export working took me longer than the entire 3D renderer.

None of this is glamorous. None of it shows up in a demo video. But it's the difference between "neat hack" and "thing my sister actually uses."

What I Learned

A few takeaways from the past month, in no particular order. Start with one real user — not an imagined market segment, but a specific person whose problem you keep poking at. The feedback loop is immediate and honest. When that real user is also a family member, the feedback is even more honest, sometimes painfully so.

Ship the ugly version. My first demo was rough, but showing it to my sister forced me to confront which parts genuinely mattered and which were vanity polish. I would have spent another two weeks on irrelevant details otherwise.

Spend disproportionate time on the unglamorous edges. The model is the headline, but the file handling, the unit calibration, and the export formats are what make people stick around.

If you want to play with what I ended up building, it's live at floor plan AI. Bring a messy phone photo of a floor plan and see how it does — I'd genuinely love to hear where it stumbles, because I'm still actively improving the symbol classifier and the edge cases are where the interesting bugs live.

Next weekend I'm probably going to try wiring up a "furniture suggestion" mode, where the tool proposes a layout based on the room dimensions and the user's stated preferences. I have no idea if it'll work. That's usually a good sign.

If you're a developer who's been sitting on a side project idea, maybe this will either motivate you or at least make you feel better about your own chaos.

Why Calculator Tools?

Honestly, calculators came up kind of by accident. A friend of mine was trying to figure out his monthly car payments and was complaining that every website he visited was either covered in ads, asked him to sign up before showing results, or gave him numbers that didn't seem right. He literally texted me like, "bro can you just make a clean one?"

That's how it started. One weekend, I opened VS Code, picked a stack I was comfortable with (React + a bit of vanilla CSS, nothing fancy), and started building. The goal was simple: a fast, no-login, no-nonsense tool that gives you the answer immediately.

That first project turned into the Car Payment Calculator, and shipping it taught me more about building focused web tools than any tutorial I'd followed.

The Technical Side: Keeping It Simple on Purpose

One mistake I used to make with side projects was over-engineering them. I'd spend three weekends setting up the "perfect" architecture and then lose motivation before building the actual feature. This time, I forced myself to keep things minimal.

For each calculator, the rules I set for myself were:

• No backend unless absolutely necessary
• Results render instantly without any page reload
• Mobile-first layout from day one
• Accessible inputs (labels, keyboard navigation, readable font sizes)

The math logic itself is the easy part — it's mostly just standard formulas. The harder part is the UX: what happens when a user enters 0? What if they clear a field? What's the tab order? Do the inputs feel natural on a phone keyboard?

I spent way more time on edge cases and input validation than on the core calculation logic. That's just how it goes with form-heavy interfaces.

The Second Project: Percentages Gave Me a Headache

After shipping the car payment tool, I had the itch to build another one. I kept seeing people (including myself) fumbling with percentage calculations in spreadsheets or reaching for their phone calculator and doing it in multiple steps.

The thing about percentage calculations is they sound simple but there are actually several different things people mean when they say "calculate the percentage." Do they mean percentage of a number? Percentage difference? Percentage change over time?

I ended up focusing on the growth/change use case specifically — the kind of calculation you reach for when you're comparing two numbers and want to know how much something changed. That became the Percentage Increase Calculator.

Building this one, I got more intentional about the input UX. I added clear labels explaining what each field meant, and I made sure the result explained itself — not just showing a number, but showing the formula breakdown so users could verify the math themselves. That transparency thing matters more than I expected. People actually trust tools more when they can see the work.

Dealing With SEO as a Solo Developer

Here's something nobody really tells you when you're building small tools: getting found is hard. You can ship the cleanest, fastest, most useful calculator on the internet and it will sit at zero traffic for months if you don't think about SEO at all.

I'm not an SEO expert by any stretch. But I've picked up a few things just from trial and error:

Page speed matters a lot. Google cares about Core Web Vitals now, and lightweight tools have a natural advantage here if you don't bloat them with unnecessary JavaScript. Keep your bundles small, lazy-load what you don't need immediately, and don't import a 200KB library when a 10-line function does the job.

The title and meta description are still important. Like, embarrassingly important for such basic stuff. I spent time writing accurate, specific titles that match what someone would actually type into a search bar.

Internal structure. Even for a single-page tool, having a proper H1, clear descriptive text around the calculator, and a logical content flow helps crawlers understand what the page is actually about.

Backlinks from real content. This is the long game, but writing about what you built (like this post) does actually help. Not overnight, but over time.

The Third One: A Longer Build With More Math

The third calculator I built was more complex than the first two. I wanted to tackle something that involved compound growth calculations over time — the kind of thing where you're projecting numbers out over many years with different variables.

Without getting into the specifics of the domain, the technical challenge was interesting: how do you display long-term projection data in a way that's readable without overwhelming users?

I ended up going with a combination of a summary output and an expandable year-by-year table. Users get the headline number immediately, and if they want to dig into the breakdown, it's there. That pattern — summary first, detail on demand — is something I've started applying to other UI work too.

That project is the Roth IRA Calculator. The math model behind it took me a few iterations to get right, and I had a couple of late nights going through edge cases around contribution limits and partial-year scenarios.

What I'd Do Differently

Looking back, here are the things I'd change:

Start with the mobile layout. I said mobile-first but I didn't always practice it. Retrofitting a desktop layout to work on mobile is always more painful than building mobile-first and expanding up.

Write the meta/SEO content before you ship. I kept treating this as an afterthought. Now I write the title, description, and a short paragraph of page context before I even start coding. It helps me stay focused on what the tool is actually for.

Test with real users earlier. I have a bad habit of polishing in private for too long. Even showing a rough prototype to two or three people catches way more issues than another solo review session.

Don't skip accessibility. I got lazy on keyboard navigation on my first project and had to go back and fix it. Screen reader support and keyboard usability are not hard to add if you build them in from the start — but they're annoying to retrofit.

The Satisfaction of Shipping Small Things

There's something genuinely satisfying about shipping a small, focused tool that works exactly as advertised. No accounts, no subscriptions, no dark patterns. Just: user comes in, enters some numbers, gets an answer, leaves.

I've had a few people reach out through the contact forms on these tools saying things like "I've been looking for something this simple for years." That kind of feedback hits different than likes on social media.

If you've been thinking about building a small utility tool, I'd encourage you to just start. Pick one specific problem. Build the minimal version. Ship it. Then iterate.

The tech stack doesn't matter that much. The polish can come later. What matters is that the core thing works and someone can actually use it.

That's pretty much everything I've been up to on the side project front. If you've built something similar or have questions about any of the technical decisions I made, drop them in the comments — happy to talk through it.