Ship it, Fix it later

The day it happened

I was laid off from Luciq, also known as Instabug, along with a lot of other people. There was a meeting, a call with leadership, a thank you from the CEO. The company handled it well. Then it was done.

I opened my laptop and started building my portfolio. Business as usual.

Nine years. Every one of them worth it.

I am a problem solver. Right now the problem is me being unemployed. The companies worth working for hire people who solve problems that are expensive to ignore. And communicate clearly enough that people listen. That matters more now than ever.

My work lived in Figma, GitHub, and Obsidian¹. Scattered. Invisible to anyone outside the company. A website would change that. One place. Mine. Visible to the world.

The domain had been sitting there for five years. Paid for every year, pointing nowhere. The layoff cleared every excuse I had been holding onto. If anything, it was a relief in that regard.

So I built it that day.

Why I’d been stuck

For years, my portfolio was a Figma prototype or a PDF in Google Drive. Part laziness. Part distrust in tools that might not exist in five years.

I have used Obsidian long enough to believe in its core philosophy: file over app². Your data should outlive the tools you use to create it. Framer, Webflow, any no-code builder owns the container your work lives in.

And the time it takes to learn those tools never felt justified enough for me to start.

So I used workarounds. And the workarounds worked. I got interviews. I got offers. Which gave me the easiest excuse in the world: I don’t need a website right now.

The other trap was the case studies themselves. I always started with the writing, not the UI. But I would get stuck trying to make one case study do everything at once: concise and detailed, scannable and story-driven, impressive to hiring managers and honest about the process.

Every year I would revisit them. New tips from designers on Twitter, new formats, new frameworks. What I didn’t notice was that most of it came from designers in the US or other markets. I’m in MENA. The context is different. The need might be too.

Reading about someone else’s market is not the same as going out there and experiencing your own. But I kept reading, kept refining, and kept telling myself the Figma prototype would do for now. Just this year. Not forever.

A personal website would have made all of this worse. Now I had a UI to obsess over on top of the writing. So I kept it in Figma. At least there, I could tell myself it was a prototype.

The sites that shaped my taste

While I was stuck, I was reading.

It started with Maggie Appleton. She wrote about Command K Bars³, the kind of interaction you know from Spotlight or Raycast⁴ on Mac. That piece led me to Paco Coursey, who built cmd+k. Then to Rauno Freiberg, then to Steve Ruiz.

What they all had in common was not just good taste. They built what they designed. No handoff. No waiting. They understood the constraints of the browser well enough that they didn’t need sixty Figma artifacts to communicate an idea. A sketch, maybe a wireframe, and they could hold the rest in their head because they knew how it would actually behave.

Watching that made me uncomfortable with my own process. I was drawing on a Figma canvas and waiting for a front-end team to bring it to life. I know that work matters in a corporate setting. But it didn’t feel right to me. Not a taste problem. Something deeper.

Maggie helped me name that too. She writes about design engineers⁵, people who sit at the intersection of design and engineering and work to bridge the gap between them. That was what I had been drawn to for years without having the words for it.

The taste was just the tip of the iceberg.

Why not Framer

I tried it. It is easy to use. That is not the problem.

The problem is that you do not discover the limitations until you hit them. You have an idea, you try to build it, and the feature does not exist yet. So you wait. Six months later, maybe eight, they ship an update and now you can do the thing you wanted to do back when the idea was fresh. That is not a workflow. That is a dependency.

Then there is the data. Getting your work out of Framer and into another tool is not something they make easy. And the pricing is theirs to change whenever they want. You are not a customer at that point. You are a hostage with a nice-looking portfolio.

This is not a Framer problem specifically. It is the whole category. No-code tools for portfolio building trade control for convenience, and I was not willing to make that trade.

Cursor is different because it is an IDE. It does not abstract the code away from you. It writes it, explains it, answers questions about it. Why this approach and not that one. What the tradeoffs are. What might cause performance issues down the line. You are inside the environment the whole time.

Reading the output, asking questions, seeing patterns repeat across sessions. That is how I learn best. By doing, not by watching. And when I want to move to a different IDE, my code comes with me. The work is mine in a way it never is inside a no-code tool.

The designers I admired did not use tools that thought for them.

The actual build

The meeting ended. I made coffee. There were phone calls. Then I sat down and started searching.

I had a set of principles I wanted the tech stack to follow: own your data, boring technology, simple over clever, low maintenance. Markdown was at the top of that list. I use Obsidian every day, so the idea of writing in Markdown and owning the files was already familiar. Astro was newer, not exactly boring, but it was built for content-driven websites. That was enough reason to try it.

I went to GitHub and searched for open-source portfolios. Some were good. Some were bad. I was looking for something that felt close to the sites I had been reading for years. I found Chiri, built by the3ash⁶. It had the same quiet, content-first feeling. Clean. No noise. I cloned it.

Then I connected it to my domain and opened Cursor. I asked it to tag everything in the codebase that needed to change to make the site mine. Name, links, metadata, favicon, OG tags, all of it. It took me about three hours. I know. I’m slow.

I was hosting on GitHub Pages, not Netlify, so I had to configure the deployment to work correctly. Once that was done, I took a case study I had written in Obsidian, adjusted the Markdown format to match how Chiri parsed content, and pushed it. No images yet. Just text. Good enough was the goal, not perfect.

The last problem was the NDA wall. Some of my work is protected, so I needed password-protected pages. Chiri did not have that built in. I asked Cursor to walk me through the options: how each approach worked, which ones were actually encrypted and which were just a wall someone could bypass. I picked the best option, hit some rendering issues, fixed them, and moved on.

I posted on LinkedIn with a screenshot of the site. Then I applied for a job (did not get it).

I went home happy. A website good enough to send. Ship it. Iterate later.

What I’d tell you

If you are a perfectionist, you already know the trap. You have been in it. You keep redesigning instead of writing, evaluating tools instead of building, waiting for the right moment instead of shipping. The moment never comes. You know this.

The website will not be perfect. That is not the goal. The goal is to have something in the world that represents your work. Something you can send. Something that exists outside your head and your hard drive.

If you are scared of code, I understand. I was not a developer when I started this. I am still not. But Cursor changed the relationship I have with code. I am not writing it from memory. I am reading it, asking questions about it, understanding why one approach works better than another for my specific situation.

You do not need to master code before you start. You need to start.

If you are in the MENA market, be careful about whose advice you follow. A lot of the content out there about portfolios, job searching, and personal branding is written for a different market with different needs. Read it, learn from it, but go outside and test it against your own reality. Reading is not the same as doing.

The site I built that day was not impressive. It had no images. No animations. One case study in plain text. But it was mine. It was live. And it was better than the Figma prototype I had been hiding for five years.

Ship it. Fix it later.