Abdelrahman Abuissa

What they said would happen

aabuissa8@gmail.com — Sat, 22 Aug 2026 00:00:00 GMT

In August 2022 I wrote down three things people had told me I would not finish.

Going to the gym to reach a certain physique — “probably you won’t make it, you’ll quit in a month or two.” Time passed, goal achieved.

Starting to learn to code — “it’s too difficult, you’ll get overwhelmed and quit soon.” Time passed, goals achieved, several languages, many projects.

Building a tech startup from scratch — “probably you won’t make it, you’ll get exhausted and quit soon.” Work in progress, let’s see.

I left the third one open because in 2022 I genuinely did not know. It would have been easy to write something confident. I did not have the outcome, so I wrote “let’s see.”

It has been four years. I can close it now.

Closing the third one

I did not quit.

What I will not do is convert that into a victory lap, because the honest version is more complicated and more useful. The startup I was building in 2022 is not the thing I do now. What actually happened between then and now was a consulting role at a legal firm, then a stretch as an AI consultant, then two years as CTO of a technology company, and now running my own again.

That is not the arc anyone plans. It has more turns in it than “built a startup” suggests, and at several points it would have been reasonable to describe it as not working.

So the accurate answer to the 2022 prediction is: they were wrong about the quitting and roughly right that it would be harder than I expected. Both things are true. The prediction that I would get exhausted was not stupid — I did.

What they got wrong was assuming exhaustion is the end of the story rather than a recurring feature of it.

Why I keep the receipts

I had written a roadmap a few months before that post:

2020 — learn programming from scratch [Done]
2021 — learn mobile development and build the app [Done]
2022 — build the startup and grow it [In Progress]

Publishing that was uncomfortable at the time, and it is the single most useful thing I did. Not because it held me accountable in any dramatic way, but because it makes this post possible. I can point at what I said I would do, and at what happened, and the gap between them is checkable by anyone who wants to check it.

That is also why I put numbers in everything else I write. When I say a vendor quoted $1,000 a month and we delivered the same capability for about three cents a page, that is not a motivational claim — it is an invoice. When I say AI took a rebuild from two months to under thirty minutes, that is a timing I recorded at the time.

Motivational writing without receipts is worth very little. I have read a lot of it. The reason I am comfortable writing the encouraging posts is that I can show the working behind them.

The two other predictions

There is a version of this pattern that is not about strangers on the internet, and it is the more damaging one — the prediction made by someone with authority.

In 2019 I had an idea for letting patients get prescriptions approved before reaching the pharmacy, instead of queuing for half an hour while the insurer responded. I described it to a marketing manager at a large pharmacy chain at a job fair. He told me it was very complicated and would never be implemented.

In November 2021 I walked past a pharmacy and saw a poster advertising exactly that.

Not by me. I want to be clear about that, because the story is not “I was robbed.” I never built it. The point is narrower and worse: someone with more seniority than me was confidently wrong, and I let that confidence stand in for analysis for two years.

The second one is smaller and stranger. I once sat two interviews with substantially the same CV. In the first, the interviewer understood the work and told me I was overqualified. In the second, the interviewer did not, and I was marked unqualified.

Same person. Same skills. Same week. The variable was not me.

What I would actually say to someone

Not “ignore everyone.” Some of the people who told me things would be hard were right, and a few of the warnings I dismissed cost me time I could have saved by listening.

The rule I would give is narrower: treat a prediction about you as a hypothesis, and notice whether the person making it has any evidence. A senior title is not evidence. A confident tone is not evidence. Having actually tried the thing is evidence.

And then go and generate some evidence of your own, because that is the only input to this that you control. It does not have to be impressive. My first piece of evidence was a script that edited my cover letter. Four years later it was a roadmap with two items marked Done and one left open.

Write down the open one. Come back to it later.

You would be surprised how often you get to close it.

The three beliefs that keep people stuck

aabuissa8@gmail.com — Fri, 21 Aug 2026 00:00:00 GMT

In early 2020 I was reading about why people who clearly want something never start pursuing it, and I came across the term self-limiting belief. It describes a thing someone assumes is true about themselves, which then quietly governs what they attempt.

What struck me was how ordinary they sound. Nobody thinks “I have a limiting belief.” They think they are being realistic. Three versions come up again and again.

One: waiting to get started

“I can’t start learning X until I’ve mastered Y.”

This one is dressed as diligence, which is why it survives so long. You are not avoiding the thing. You are preparing for it, responsibly, and you will begin properly once the groundwork is done.

The groundwork is never done. There is always another prerequisite, and the prerequisite is doing exactly what it is there to do.

In 2022 I wrote about how the Spartlic app actually got built, because the real version is instructive. I had just finished learning Java from a two-and-a-half hour YouTube video. Not a course. A video. Then I discovered I needed the app on both Android and iOS, which meant React Native, which I also did not know, so I learned that as fast as I could while building.

It took three complete attempts over six months — Java with Firebase, then Java with Parse, then finally React Native with Parse — before there was something worth releasing.

By the “master the fundamentals first” standard I had no business starting. I would still be preparing.

Two: waiting for perfect conditions

“I can’t go to the gym, I’m too busy at work right now.”

The conditions do not improve. They change shape. The busy period ends and a different one starts, and the version of you who was going to begin once things calmed down never gets a calm month to begin in.

I started learning to program while unemployed, which sounds like ideal conditions until you consider that I was also spending every day applying for jobs and had no idea whether any of it would lead anywhere. It was not a sabbatical. It was the worst professional period I had had, and it happens to be when the useful thing started.

I am not romanticising that. I would not recommend unemployment as a learning strategy. The point is narrower: the conditions were bad, and it worked anyway, which means the conditions were not the deciding variable.

Three: tried once, and failed

“I can’t get into X. I tried and couldn’t make it work. I’ll never be as good as I want to be.”

This is the most durable of the three, because it comes with evidence. You did try. It did not work. That is a fact, and the conclusion drawn from it feels like honesty rather than avoidance.

The error is in what the failure is treated as. Most people treat a failed attempt as a verdict. It is more useful as a checkpoint.

If you start something and it collapses halfway, you have not returned to zero. You are standing at the point where it collapsed, holding the knowledge of how it collapsed. Starting again from there is a completely different proposition than starting from nothing — and it is why my third attempt at that app took weeks rather than months. The first two were not wasted. They were where I learned what would not work.

The mechanism underneath all three

They share a structure: each one protects you from the discomfort of being visibly bad at something. Waiting for prerequisites, waiting for conditions, and concluding from one failure are all ways of not being in the uncomfortable zone.

Which would be fine, except the uncomfortable zone is the only place anything happens. Every skill I have that pays me was acquired in it.

The honest version

I do not want to end this by saying that all it takes is deciding to start, because that is not true and I have watched people bounce off it.

Starting is genuinely hard, and the first month is genuinely unpleasant, and a meaningful number of things you begin will not work out. Two of the eleven subjects I took on in 2020 went nowhere at all.

What I would say instead is narrower and I think more useful. These three sentences are not observations about your capability. They are predictions, and they are the kind that make themselves true. You can test whether they are accurate, and testing costs less than you think — usually one uncomfortable week and a willingness to be visibly bad at something in the meantime.

Most people never run the test. That, more than talent, is what separates the outcomes I have watched.

Eleven things a day

aabuissa8@gmail.com — Thu, 20 Aug 2026 00:00:00 GMT

In January 2020 I had a question I could not find a satisfying answer to: how much can a person actually learn in a day?

Not in theory. Mine, specifically, measured.

So I ran it as an experiment. I picked three subjects — Python, Russian and JavaScript — on the assumption that three simultaneous learning tracks was roughly the ceiling for a working adult.

It was not. Over the following weeks I kept adding. I finished at eleven.

What came out of it

By the end I had the basics of Python, the Russian alphabet and enough reading to sound out words, JavaScript, HTML and basic CSS, and an introduction to algorithms and binary search.

Two of the eleven failed outright: reverse engineering and statistics. I could not get traction on either at the time.

I want that failure rate on the record, because a version of this post that only lists the successes would be useless. Two in eleven did not work. The reason matters less than the fact that the experiment still succeeded overall — nine subjects moved from nothing to something, which was nine more than the “focus on one thing at a time” advice would have produced.

Why parallel worked better than serial

The conventional advice is to learn one thing properly before starting another. In my experience that advice quietly assumes your motivation is constant, and it is not.

Running several tracks at once meant that when I hit a wall on one — and there is always a wall — I had somewhere to go that was not “stop learning today.” Progress on Russian vocabulary on a day when Python was not working still ended the day with something achieved. Momentum survived the bad days, which is the only thing that matters over a span of months.

It also produced connections I did not plan for. Learning how websites work made SQL injection make sense, which pulled me toward security, which is now a significant part of what I do. None of that was on the roadmap. It came from having several doors open at once.

The stopwatch

The other half of the method is embarrassingly simple: I time things.

In June 2020 I needed to update my CV, and I did not have Office installed. It would have taken an hour to download. Instead I decided to learn LaTeX — which I had never used — and write the CV in it. It took about an hour, start to finished document.

There were easier ways to write a CV. That was not the point. The point was to put a clock on an unfamiliar task and find out what an hour of concentrated effort against something new actually buys.

I have kept doing this for six years. Java basics in four days. Android Studio in five. A full augmented reality project in four. A framework I had never touched, shipping a client project in one. Odoo, from no API knowledge to a working integration, in two weeks.

The times are not there to impress anyone. They are there because a measured time is the only defence against the feeling that you are not making progress. The feeling lies. The stopwatch does not.

What I would change

Two things, honestly.

Eleven was too many. It worked, but the depth was thin — I got the basics of nine subjects and mastery of none. That was the right trade in 2020, when the objective was to find out what was possible and to cover enough ground to know what I actually wanted to pursue. It would be the wrong trade now. Breadth is a phase, not a permanent strategy.

I under-planned the recovery. Adding tracks is easy. What I did not build in was what happens when a track stalls for a month. I worked that out later, and it became the most useful thing I know about goals: a sub-goal that overruns has not failed. Pause it, keep the others moving, come back. Drifting off the path is not the same as the plan failing.

If you want to try it

Start with three, not eleven. Add a fourth only when three feels comfortable rather than when it feels heroic. Put a clock on the first session of anything new so you have a real number instead of an impression. And decide in advance what you will do when one of them stalls — because one of them will.

Then accept that some of them will not work. Two of mine did not, and it is still the single most useful month I have ever spent.

On feeling stupid

aabuissa8@gmail.com — Wed, 19 Aug 2026 00:00:00 GMT

The hardest barrier to learning anything is not that the material is difficult. It is a specific feeling, and if you have taught yourself anything you will recognise it immediately.

You are twenty minutes into something new. It is not going in. You read the same paragraph three times. And somewhere underneath the frustration is a much older and more uncomfortable thought: maybe I am not smart enough for this.

That thought is the actual obstacle. Not the syntax, not the maths, not the documentation. The fear of being stupid — or more precisely, the fear of discovering that you are.

What your brain does next

Once that feeling arrives, your brain starts offering you exits. They are always reasonable. You should check something. You are tired, better to come back fresh. This is probably not the right resource, you should find a better course first. Maybe this whole field is not for you.

Every one of those is a way of stopping without having to admit you stopped.

And it works, in the short term. You put it down, the bad feeling goes away, and nothing has been lost except the thing you were trying to learn. This is why so many people have three unfinished courses and a conclusion about themselves.

The obvious answer is wrong

The advice you normally get here is to push through. Grit your teeth, keep going, discipline over motivation.

I do not think that works, and I have tested it on myself fairly thoroughly. If you keep grinding at the exact thing that is making you feel stupid, the feeling does not fade — it compounds. Every additional minute of not-getting-it is more evidence for the case your brain is building against you. Eventually you quit anyway, except now you quit with a much stronger conviction that you were right to.

What actually worked

The thing that worked for me was neither pushing through nor stopping. It was sideways.

When I hit the wall on something, I switch to a different task — usually related, sometimes not — that I know I can do. Something a bit easier. Something where I will produce a result within the hour.

That does two things. It restores the sense of being someone who can do things, which is what actually got damaged. And it quietly removes the emotional charge from the hard task, so when I come back to it a day later I am looking at a technical problem rather than at a referendum on my intelligence.

The distinction that matters: I am not avoiding the hard task. I am neutralising the feeling so I can return to it. The test is simple — if you come back, it was a sidestep. If you do not, it was an exit with better branding.

Why I trust this one

I wrote the first version of this at the end of 2019. At that point I had been unemployed earlier that year, had been learning Python for about three months, and had exactly one working program to my name — a tool that edited my own cover letters.

I did not know then whether any of it would go anywhere. It was, honestly, a note to myself.

What I can add now, which I could not add then, is that it held. The same approach got me through machine learning, then Java and Android in about nine days, then a framework I had never touched shipping a client project in a day, then an entire domain — server security — that I only entered because I kept getting broken into.

Every one of those started with roughly a week of feeling stupid.

The part nobody says

You do not stop feeling stupid. That is the thing I wish someone had told me in 2019.

Six years and several languages later, every new domain still opens with the same fog and the same quiet suggestion that everyone else finds this obvious. The feeling has not diminished at all.

What changed is that I stopped treating it as information. It is not a signal about my capability. It is just what the first week of anything feels like, and by now its arrival is almost reassuring — it means I have picked something worth learning.

If you are in that week right now: nothing has gone wrong. That is the week.

The knowledge gap is the business model

aabuissa8@gmail.com — Sun, 16 Aug 2026 00:00:00 GMT

When I got into tech in 2020, one thing bothered me more than anything else.

I kept watching people who knew things use that knowledge as leverage. Clients who could not tell good work from bad work were charged premium prices, talked down to in meetings, and billed separately for every small request. The less the client understood, the more it cost them.

It was not fraud. Almost none of it would fail an audit. Every line item was for something real. It was just that the price of the work had quietly detached from the cost of the work, and floated up to meet whatever the client did not know enough to question.

I promised myself I would build the opposite of that. Six years later I am still building it, and the pattern has not changed at all.

What it looks like in practice

It is rarely dramatic. It shows up as:

A monthly subscription to a third-party tool, where a one-off script would have done the same job — and the option was never mentioned.
A tiered price built around a volume the client will never reach, sold to a client whose actual usage is a rounding error against the tier.
A quote for integration work from a team the client already employs.
Jargon deployed at exactly the moment a plain-English explanation would have made the price look unreasonable.

I have specific instances of the first three, with the numbers attached, and I intend to write each of them up properly. The fourth is harder to evidence because it happens in rooms — but anyone who has sat on the buying side of a technical conversation knows the feeling of one being steered away from a question.

The tell

A few years ago we met a CEO who had been through several IT providers already. When we told her we were committed to delivering what we said we would deliver, her response was flat: “That’s what all IT companies say.”

She was right. It is what all IT companies say. Saying it is worthless. The only thing that separates the companies who mean it from the ones who do not is whether they behave differently when the client would never find out.

We delivered the first phase of her project on time, and then we were the ones pushing to start the next phase. That is the only argument I have ever found that works — not a promise, just a track record accumulating in public.

Why I publish the numbers

This is why I put real figures in what I write rather than talking in generalities. AED 55,000 against AED 7,700. A $1,000-a-month quote against about three cents a page. $28.36 in total spend where the floor quote was $12,000 a year.

Publishing those does two things. It gives someone on the buying side a reference point they did not have, which is the whole objective. And it puts me on the hook — if I ever quote a number that does not survive the same scrutiny I am applying to other people’s numbers, it is on a public page with my name at the top.

That second part is the useful discipline. It is easy to be transparent in the abstract. It is harder when your own margin is the thing being made legible.

What I am not arguing

I am not arguing that everything should be cheap, or that specialist firms are parasites. Some of the most valuable money my clients spend goes to outside specialists, and the AED 55,000 quote I turned down was a perfectly fair price for a company that did not have my team.

Expertise is worth paying for. Risk transfer is worth paying for. Being able to call someone at 11pm when a system is down is very much worth paying for.

What I am arguing is narrower: the client should be able to see which of those they are buying. When the invoice says “AI document processing” and the client has no way to know whether that is a genuinely hard problem or a weekend of configuration, the price stops being a price and becomes a test of how much they can be charged.

The uncomfortable part

Transparency costs money. Every time I tell a client that the thing they asked for can be done for a fraction of what they expected, I am reducing an invoice I could have sent.

I have made peace with that, mostly because the alternative is a business built on clients not finding out — and clients do find out, eventually, usually right before they leave.

But I want to be honest that it is a trade rather than a costless virtue. The version of my company that charged what the market tolerated would have made more money in the short run. What it would not have is a set of clients who send me work without asking for a quote first.

That trade has worked out. It might not have. It is still the one I would make again.

Why I'm writing this down

aabuissa8@gmail.com — Mon, 10 Aug 2026 00:00:00 GMT

There is no shortage of writing about AI right now. There is a real shortage of writing about what happens around it — how the company gets licensed, how the first proposal gets priced, which clause in an agreement is the one that saves you six weeks of unpaid work.

That gap is the only reason this site exists.

The short version of how I got here

I studied business administration with a specialisation in accounting. I spent the early part of my working life inside spreadsheets and admin processes, which is not a glamorous origin story but turns out to be an unreasonably good one. Accounting teaches you to care about where the money actually moves, and admin work teaches you that most business problems are process problems wearing a technical costume.

Then I taught myself to write software. Not through a bootcamp or a degree conversion — just the slow, unstructured way, building things that were slightly too hard for me at the time.

Today I run Coders Technologies FZE, a licensed software company operating inside Sharjah’s research and innovation park ecosystem, building AI agents and platforms for clients who need them to work in production rather than in a demo.

What this blog is, specifically

Two things, and they depend on each other.

One: how to actually get somewhere you have not been. Not motivational posters — the specific mechanics. What the first week of learning something genuinely feels like and what to do about it. How many things you can learn at once. Which sentences people say about themselves that quietly decide the next decade. I wrote most of this down as it was happening rather than reconstructing it afterwards, which means it comes with dates attached.

Two: what serious software actually costs to build. The vendor quote I turned down, what I built instead, and what it came to on the invoice. Everyone writes about AI. Far fewer people publish the numbers, because the numbers are what stop you charging whatever the client is willing to tolerate.

The second one is what makes the first one worth reading. Motivational writing without evidence is worth very little — and the technical numbers are the evidence. That is also why this site has a journey view that arranges posts by when the thing happened rather than when I wrote it up. Read it top to bottom and you get the actual sequence, including the parts where I was wrong.

What it is not

It is not the company blog. Coders Technologies has its own site, its own clients, and its own positioning. This is the founder writing in the first person, which means I get to be specific about mistakes in a way a corporate site never can.

If you want the arc from the start, begin here. If you would rather just see what is new, the full archive is sorted newest first.