Mohammad Shaker's Blog

This is something I’ve written for myself a couple of years back in 2021. I came across it and thought I should share it. Hope you get something out of it as I did.

I really like building stuff. And I think I’m really good at it. The problem it seems that I’m not the best at selling what I build. I feel that any marketing or sales activity is of a lower grade. That I only should focus on creating something I feel great. I don’t want to spend useless time on marketing or on sales.

It seems that this stems from the engineering mindset that anything outside engineering or product work is sub par. And this is unnatural. This is not how nature works and this is not how humans live.

We live by trust, by telling stories and making jokes at and to each other. This humanistic nature can’t be quantified in numbers. I can’t simply engineer my way out for selling anything I create. I need people to need my product. To want it. And then to trust me enough to buy it from me.

I think our small early groups as humans, living in small villages instilled this in us. We’ll befriend people we trust. We’ll buy from the people we befriended and we’ll marry people who are friends of friends. Because we trust them.

As I’m writing, and during the last 2 years I see it again and again. That whenever I should start something new, something outside the craze of Venture Capitals, and completely bootstrapped, the only way to sell is to show people you are trust worthy. Earn people trust and they’ll give you anything.

As I’m writing this, it’s funny because this relate 1 to 1 with Kelly’s idea of the 1000 true fans in the realm of B2C products. You’ll only need a 1000 fans to live a comfortable life. The problem is how to build this base of a 1000 turn fans? I think it should start with the first 10 fans. Then 20, 50, 100, 200, 1000. And that’s what I should do with anything I want to start. Small wins. Localism wins.

I simply don’t want to go the VC way. I want to do anything the same way my grandfather did. With his own money.

Salam, peace.

Lately, I have spent the first 1h each morning tinkering with agents, embeddings, RAG, multimodal RAG, LangChain, Haystack, etc (www.deeplearning.ai has amazing 1-2hrs courses. You can digest 1 each morning.)

The more I tinker with the technology, the more I see how agents can literally change the whole way we design and ship software.

If I’m to write a prod-ready software from scratch, there’s a completely new way to do it with Agents. It’s simply this:

Write agents with function calling, tools and MCP links.Thin CRUD layer on top of a storage layer (DB.)Let agents talk directly to that thin CRUD layer and between each others.

That’s it. No fixed application or business logic. Each agent will decide which tool/function to use on top of the CRUD layer of a DB. And when to call other agents for help outside their domain (expertise or content/knowledge area)

Taking a step back now.

For the last two decades, we’ve seen most software stack layers get abstracted, outsourced, or minimized. Frontends went from handcrafted jQuery to SPA to a React runtime. Infrastructure went from hand-rolled Chef scripts to serverless YAML.

Every software out there is built around a familiar three‑tier model:

Presentation (front‑end or API)Application / business logicData and storage layer

LLM‑powered agents collapse tiers 1 and 2 (and sometimes parts of 3) into a single reasoning layer. The agent decides what to show and what to call next from a list of tools (functions or other MCPs); the database becomes a very simple, schema‑enforced persistence tier. Think of it as serverless, except the function is intelligent.

Traditional applications center around deterministic business logic. Take:

if user.is_premium: apply_discount()

Logic is gated by feature flags, permissions, pricing tiers—each wrapped in code paths and tightly scoped unit tests.

Take customer support. What was once a flowchart of conditionals, database lookups, and email dispatching is now a retrieval-augmented agent querying embeddings, asking clarifying questions, and summarizing previous tickets.

Business logic used to be the “meat” of an application. Now, increasingly, it’s becoming scaffolding for agents.

A table can help us understand:

LayerCurrent (Old) WorldAgent-Powered StackUIHandcrafted and fixed forms and flowsThin prompt UIs, auto-generated (on-demand)Business LogicConditionals, services, pipelinesAutonomous agents with tools (on-demand, cached)Data LayerCRUD tightly coupled with services, Domain LogicThin CRUD interface on top of the storage layerDevOpsCI/CDStreamlined CI/CD: Lambda/Fargate, Vector DBs, MM RAG

Agents don’t need all the rigid business logic—only tools (APIs), memory and storage (DB), and context (retrieval). They decide how to use them, not you or me. Your app becomes a toolkit. The agent decides what hammer to use.

A shift from Logic to Language. The shift is epistemic. We’re moving from codified logic to language-driven reasoning. From state machines to semantics. From “how does this function work” to “what does the good outcome looks like?”

The agent doesn’t need to know every rule. It needs to know when to ask, where to look, and how to act.

This Changes Value Creation in Businesses. This enables something like this:

Instead of a 4-step wizard, lead with outcome. Describe what this flow should lead to. Let the agent deduce the rest.

The job of a product manager shifts from defining flows to defining outcomes. This also changes the engineer’s work from defining fixed rules to defining capabilities. The job of the engineer shifts from building guardrails to exposing tools (capability) safely.

Not everything will be agentified. Critical paths—like payment processing, identity verification, or compliance checks—still demand determinism. But increasingly, those become thin wrappers. The bulk of the experience, the thing that feels intelligent, adaptive, and helpful—will be the agent.

Final thoughts for a panicking industry. If you are an engineer interested in this, the only way to help us understand this shift is to tinker with it. Something you can do today is the following:

Identify a narrow self-contained slice in the codebase like a workflow (e.g., invoice approval).Expose CRUD endpoints (REST or GraphQL). Keep them boring.Wrap the endpoints in tools for your agent framework (Adept, AutoGen, LangChain, Haystack).Ship with a human‑in‑the‑loop review step; measure approval rates.Iterate: evolve guardrails, expand autonomy gradually.

I’m still tinkering with this around the edges and will have something more technical to share soon.

I survived my MSc. program in France by being [basically] totally broke. I was seriously in money-saving mode. I was mainly eating a sandwich a day. Or if I want to really spoil myself, I would buy a 3 euro lunch meal at the university cafeteria and consider that a restaurant meal.

I didn’t feel pity and I still don’t.

I was completely content and I really didn’t care much.

All I cared about was that the outcome of all this. The outcome in my head is that I will start generating income as soon as I finish my master. And I did. I was hired for a Software Engineering role in Squla, a startup in the Netherlands. I was taking home more salary than any other engineer at the same level, even when they were 3+ years already in the company.

I don’t want to glorify the grind. But maybe I do. The thing I’m thinking about here is how hardship and discomfort, not comfort, is what pushes us beyond what we normally think we can do. It’s there where we most grow. Where we most must persist.

We can apply this everywhere: going without food for an extended period of time, have an extra lengthy, extra heavy gym session, running a double distance, implementing and deploying a technology in a very short, very constrained amount of time (I remember when I did this in Neurofenix’s backend with Serverless SLS stack), starting a business and timebox it, reading Aquinas’ Summa Theologica in couple of months (haven’t done it), Turning over a team performance under 1 month (have done it), being completely off (really off), being completely on (focused).

I’m thinking how can I create this for myself on a regular basis. And how I would teach this to my kids in the future – how to create these manageable hardships for them. The deliberate discomfort.

I don’t have the answer now. But I must do it.

The man himself, Seneca

Writing this now reminds me of Seneca and stoicism.

Let the man speak for himself:

Set aside a certain number of days, during which you shall be content with the scantiest and cheapest fare, with coarse and rough dress, saying to yourself the while: “Is this the condition that I feared?” It is precisely in times of immunity from care that the soul should toughen itself beforehand for occasions of greater stress, and it is while Fortune is kind that it should fortify itself against her violence. In days of peace the soldier performs maneuvers, throws up earthworks with no enemy in sight, and wearies himself by gratuitous toil, in order that he may be equal to unavoidable toil. If you would not have a man flinch when the crisis comes, train him before it comes.

Seneca from Moral Letters to Lucilius

Salam, peace.

Something new I’m trying

It’s reading a deep [hard] books or learning something new for an hour after an exercise/running session.

Whenever I’m back from the gym, I shower, and I just sit down and read a thorough book for 30-60 minutes – fresh out of a refreshing session.

It’s the same thing I’m trying to do after waking up. Wake up, sit down and read a hard science book or learn something hard.

When our mind is calm and clear in the morning, it’s the best to fill it in with the most hardcore stuff, the most difficult. Same after an exercise – the blood is flowing and the mind is clearer.

It works.

Something I keep doingDrinking tea from small cups pouring from a teapot, like we used to do back home in Syria. We used them when I was 3. Excellent in the morning with green teapot and a hard book.(You can still buy them online — from the French manufacturer Luminar. Or Duralex.)

What I’m reading

I’m reading multiple books on parallel. Here are some of books I’ve read recently.

Technical/EngineeringBen Stopford on Kafka: Designing Event Driven Systems is a very enjoyable concise read.AWS Certified Solutions Architect (All available books. Read 5 so far. None is the best tbh.)What is ChatGPT Doing, Wolfram.Deep Learning courses on MCP, Agentic AI, RAG systems and MM-RAG. Just search http://www.deeplearning.ai and you’ll find many. All under 2hrs. Attend 1 course on LangChain and you’ll have many ideas to tinker with within 30 minutes.History and Philosophy:History of Islamic Philosophy by Majid Fakhry is an amazing read (language/readability is a bit rough – still an amazing read.)The Cambridge History of China (Buckly.) Good, not best.Daily Life in Ancient Mesopotamia, Nemet Nejat. Good, not best.

1 thing that is making me happy

Reading autobiographies. I’ve listened Ford’s autobiography across two days on 4 long walks (via Audible, not that I like Audible.)

Art or Poetry I’m reading

I’m reading Al-Mutanabbi poetry from a very old book with yellow pages from the old library of my father-in-law (RIP.)

Say thanks for 1 Person today

And my father-in-law, who passed away on Sept, 2023.

Don’t Take Anything for Granted.

One of the good things that I learned early in management of engineering functions is this: never force a ready-made template that worked elsewhere onto a new team or function.

Yes, we should start from principles, but not from fixed practices.

Each company, product, priority, and team—along with the team’s skills and purpose—differs.

If all these vary, how can the same rule suit every company?

No single process fits every engineering team—whether Kanban, Scrum, waterfall, one-week sprints, two-week sprints, or project milestones.

We learned to walk by falling many times. Bottom-Up, Never Top-Down.

The soundest principle I found to work every time is to start small. Plan for the short term first, a 1 week amount of work, then proceed.

This rule is constant: start small, start local.

From there, change in cycles: spot a problem, propose a solution, implement, review, and begin a new cycle (call it a sprint, week, or epic—it must end so you can reassess).

This is bottom-up action. In each cycle the team discovers what works. Not the EM, the director, or the CTO, but the team itself. It adapts locally and iterates.

Thus everyone helps decide what each next cycle should be, which practices to adopt, and which to discard.

With enough cycles, teams discover the few processes that matter. Control only the essential variables; ignore the rest.

Keep policies to a minimum. Too many feel robotic and dictatorial. Preserve an open-market style of work.

Start small. And keep an open mind with min # of policies.

Hire mediocre people and you need to force a way. The principles above won’t hold.

Hire great people and let them find their way. The principles above hold.

In the engineering context, most advice around the topic of what to build/not to build comes from the following:

Invest for the long term.

Which is absolutely true. The problem though is that most engineers, would view this as a license of investing in everything since everything is needed in the long term.

Another approach to counter this way of thinkings seems to be:

Deinvest for the long term.

Which means asking the question:

What are things that we should ditch and are NOT worthy in the long term?

This means that we must not do anything that’s not tied to our core value proposition in the long term.

Example: Building our own logging system? This is a solved problem. Absolutely not a core value prop in the long term for most startups or companies. That means we must not do our own but buy or use a 3rd party solution.

A simple principle that you can apply anywhere.

Salam, peace.

Why do I live where you live?

I live in London. I came here in 2018 after 2 years stint in Amsterdam. And another in France and before that my hometown: Damascus, Syria.

Now to the why. Simply, London is, along with Berlin I think, the best place for startups (in Europe. But Europe is dying sadly and that’s a discussion for another time.)

Outside Europe, it’s the US and China which are the best places to be I believe.

Now, why London again? Simply, again, at least for me, is the Freedom.

Freedom? To get this resolved, we have to go through a bit of history.

I’m originally Syrian.-2013: I had done all my studies up to and including my bachelor program in Syria. I had a 5-year bachelor degree in Information Technology and AI.-2015: I moved to France to do my MSc. in Ubiquitous computing and AI.-2018: Working in Amsterdam in EdTech startup, Squla. (I love Amsterdam and I love the Dutch. They are both, serious workers like ze Germans, yet still playful like the Italians.) At least the ones I knew.2018-now: Moved to the UK, I only had my Syrian part up to that point – a non-EU citizen.

Still didn’t get where the Freedom in all of this?

A bit of context: if you are not a citizen of the EU/UK, you have to be employed by a company in order to stay. If you’re not employed, you can’t stay.

When I lived in Germany, Netherlands and France, my stay was tied of me being a student or having a employment contract, which means I’ll be an employee, instead of being an employer (i.e. starting my own startup.)

With the UK Exceptional Talent visa (now renamed to Global Talent visa) this is no longer the case. You’ll have 5 year stay permit to do what you want. I can be an employee or an employer (starting your own startup.) And that’s exactly what I did in the last 6 years.

I moved to London and I was the employee #5 in Neurofenix (startup), started my startup (Almeta and pivoted to TheAlphazed.com.) Later I head the engineering function at Noon as Head of Engineering. And now back to being a tech cofounder (SpatialX) curing cancer.

Freedom is hard. And should be cherished above all else. And that’s why I moved to the UK.

Salam, peace.

Here we go again.

Something I keep doingTraining, in the gym.Reading in the morning.Long walks on weekends.Something I am changingNot eating fruits and sugar at the end of the day. This one is big for me. Given my 1 meal a day regimen, the suger-kick kicks in and I’ll really crave some sugar. I started substituting chocolate with fruits (blueberries.) And now I’m trying to substitute sugar with nothing.Having my 1 meal a day before 8pm.Best of what I watched

Webb images on space. I’m speechless.

What I’m reading?Wealth of Nations, Adam Smith.Understanding Understanding, Richard Saul Wurman.Something I’m remembering from the past

My dad. And my mom.

Say thanks for 1 guy today.

My friend, Hussam Sandouk. For pushing me to have better answers and clearer mind. Hussam is one of the smartest people I know. And I’m lucky to have friends who are way smarter than I am.

Being weak among the strong, makes me stronger. Thank you, friends.

“How can I help?” — It’s a simple question, but one that’s carried me further than most job titles or credentials.

We help others because it fills something within us—true. But real help isn’t about making yourself “feel” useful; it’s about “actually” being useful.

In business, asking “How can I help?” isn’t a performance. It’s a prompt for action.It’s an act of leadership—quiet, service-oriented, and rare.

Years ago, I read a tactic that opened my eyes:

Find what your boss hates doing—or what they spend the most time on.Figure out how to take it off their plate.Document your plan.Share it with them.Act on it.Report back on it, weekly.

It sounds simple. It is. That’s why it works.

The best people reduce load. They show up with solutions, not problems. They subtract from the chaos instead of contributing to it.

The question scales. It works with your boss, with your peers, and with your team (or “direct reports,” though I’ve never liked the phrase). You can lead in every direction if you start from this place.

But—like all good habits—it’s easy to forget. Busyness creeps in, and the instinct to help dulls. This is a reminder to sharpen it. To make it a rhythm. At least once a week, ask:

How can I help?

It’s a better question than “Can I help?”
The latter invites a one-word answer.
The former invites collaboration.

When should I adopt a new technology? When should I take risks? When should I play it safe?

It all ties to risk. Ten years after reading and rereading Nassim Nicholas Taleb’s work, I think I understand a bit more.

I must know what falls within my circle of control. More importantly, I must know what I cannot control.

This view of looking at everything from the prism of risk is echoed by the thinkers I admire—Hayek, Taleb, and Seneca. In economics, in daily life – and in what I try to do in tech.

12 years ago I learned the first step:
“Focus on what’s under my control and leave what is not.”

10 years ago I learned to take it one step further:
“Focus on what’s under my control and render what’s not ineffective” (Antifragile, Taleb)

This is the essence of Taleb’s barbell strategy. In investing, keep 90 % of capital in ultra-secure assets and put the remaining 10 % in highly speculative bets with unlimited upside (and downside). However that 10 % fares, you won’t be ruined; your tranquility remains intact.

In tech and startups, the analogy is to design systems that are ultra-stable—using technologies the team knows and trusts—while reserving 10 % for bleeding-edge experiments. Juniors often disagree; seniors rarely do. Juniors get excited about every shiny tool without proof of its durability (a la the Lindy effect).

The barbell strategy doesn’t encourage timidity; it limits the cost of being wrong. I want to survive—and to do so wisely.

I’m not chasing hyper-growth;

I’m chasing sustainable growth,

in both

business

and

life.