Ashim Works

03/08/2026

There is a pattern that has been quietly normalized in the tech space and it is worth calling out directly.

Someone learns to code. They spend weeks perfecting their portfolio website. The animations are clean, the color palette is consistent, the layout is responsive on every screen size. Then they add three projects to the projects section. All of them are local. None of them have real users. None of them have ever dealt with a real problem.

And then they wonder why the opportunities are not coming.

Here is what nobody tells you clearly enough. A beautiful portfolio gets you a first look. Shipped work gets you the conversation. There is a massive difference between the two, and the longer you stay in portfolio mode, the harder it becomes to leave it.

Shipping something real forces you to solve problems that do not exist in a controlled development environment. How do you handle authentication when someone actually tries to break it. How do you scale even slightly when load spikes. How do you charge for something and make the payment flow work without breaking. How do you keep users coming back after the first visit.

Those are the skills that actually matter. Not the scroll animation library you picked.

The business side of this is just as important. Every real product you ship is a proof of judgment, not just proof of technical ability. It shows you can scope something, commit to it, and deliver it under real conditions. That is what separates people who get remote contracts, consulting work, and founder opportunities from people who are still rebuilding their portfolio for the fourth time.

Build something. Put it in front of real people. Learn from what breaks. Ship the next version.

That cycle is worth more than any portfolio site you will ever make.

02/08/2026

Was playing chess online today and my opponent was from North Korea ☠️

Won the game. But that flag next to their username is all I could think about honestly.

Anyone else had one of those random online moments that just makes you stop for a second?

02/08/2026

Here is something nobody tells you when you are building a product.

The thing that kills most products is not competition. It is not bad timing or a down market. It is the decision to keep adding features because saying no feels like leaving money on the table.

I get it. Users ask for things. Investors want to see momentum. The pressure to ship is constant. But there is a version of this that goes quietly wrong. You ship enough that the product becomes hard to explain. Then it becomes hard to use. Then the people who loved it in the early days start drifting.

The products that outlast everything around them are the ones that made a choice. One problem. One workflow. One outcome that users care about enough to pay for without thinking twice.

That is not a design philosophy. That is just how value works.

When something does one thing perfectly, it earns a kind of trust that a feature-heavy product almost never can. It becomes part of how someone works. It becomes the tool they open first. And when renewal comes around, they do not even check the price.

Fewer features, built deeper, means fewer support issues, faster onboarding, cleaner code, and customers who actually stay. Every axis improves when you stop trying to be everything.

The hard part is not building more. The hard part is deciding what you will not build, and holding that line when things get loud.

That is the product discipline that compounds.

31/07/2026

Here is something nobody talks about enough in tech communities: most software that gets built did not need to be built.

I work with clients across different industries and the conversation almost always starts the same way. Someone has a problem, someone has heard that AI or a custom platform can fix it, and now there is a budget and a timeline before anyone has asked whether building is even the right call.

So before I open a code editor, I put every client through the same four questions.

One. Is this actually your problem to solve, or has someone already solved it?

There are tools that handle almost every business operation you can name. Scheduling, payments, data pipelines, customer communication, inventory. The ecosystem in 2025 is deep. If a tool exists that covers 80 to 90 percent of your use case, the smarter question is whether you can live with that gap, not whether you can build something better.

Two. What does the real cost of buying look like at your scale?

The monthly subscription is not the cost. The cost is the subscription, plus your team's time configuring and maintaining it, plus what you give up in flexibility, plus what happens when the vendor changes pricing or gets acquired. I have seen teams realize mid-contract that a tool they pay $500 a month for would cost $15,000 to replace. Know that number before you sign.

Three. What is the core of your product and is this part of it?

If the thing you want to build is what your customers actually pay for, or what makes your service meaningfully better than a competitor, that is a build conversation. If it is infrastructure, internal tooling, or something that looks like a differentiator but really is not, buying wins almost every time.

Four. Who maintains this in year two?

This is the question that exposes the real cost of building. Custom software is not a one-time expense. It is a commitment to maintain, update, debug, and document something that only your team understands. Every engineer who leaves takes context with them. The true cost of building is the total cost of ownership, not the development sprint.

I have built things that absolutely needed to be built. And I have talked clients out of builds that would have cost them a year of momentum chasing a problem that a $99 a month tool already solved.

The decision is never really about code. It is about clarity.

What are you actually trying to win at, and what is the smartest way to get there?

30/07/2026

Everyone loves quoting "move fast and break things" until they are the user getting broken.

That phrase came from early Facebook. They were a small team, shipping fast against zero competition in social networking, and the worst case scenario was a feed that loaded weird for an hour. Fair enough. Ship it.

But here is the part nobody quotes: Facebook themselves retired that motto years ago. They replaced it with "move fast with stable infrastructure." Even the company that invented the slogan realized it had an expiration date.

In 2025, if you are building a product, your users will not give you a grace period. They will not write you feedback emails about a broken page. They will close the tab and try the next option Google suggests. That is not dramatic. That is just how people use software now.

The technical side matters here too. We have feature flags, staged rollouts, proper CI/CD pipelines, and observability stacks that actually work. These are not luxury tools for big companies anymore. A solo developer on a side project can set up LaunchDarkly or Flagsmith in an afternoon. The excuse that "we need to move fast so we skip testing" stopped making sense when the tooling caught up.

And from a brand perspective, every time your product breaks publicly, you are spending reputation you have not earned yet. Especially if you are early stage. Especially if you are trying to build trust with your first 500 users. Those people talk. What they say about your product in those early months becomes your brand whether you like it or not.

Move fast, absolutely. But know what you are breaking and decide if you can afford it.

29/07/2026

Spent the last few days building a URL shortener backend from scratch.

Go for the API, Redis for storage, Docker to package it all up.

Sounds simple on the surface but there is a lot going on underneath. Generating short codes that never collide, handling custom aliases, setting expiry on links, and making sure the redirect happens fast every single time.

Short demo in the video. Happy to answer questions if anyone is curious about the setup.

28/07/2026