DEV Community: issam fathi

Building serious tech from outside the tech hubs

issam fathi — Fri, 17 Jul 2026 19:12:01 +0000

There is a quiet assumption in tech that real products come from a handful of cities. San Francisco, London, Berlin, maybe a few others. Everywhere else is treated as a place that consumes technology, not one that builds it. I build from Tetouan, in northern Morocco, and I think that assumption is not just wrong, it is expensive for the people who believe it.

I work on an AI platform used by people who own buildings and infrastructure. The work is not a lite version of what a team in a big hub would do. It is the same work. The models are the same models, the standards are the same standards, and the users do not care where the team sits as long as the product earns its place in their day.

What building from outside the hubs actually changes is not quality. It is a few habits, and most of them are advantages.

You cannot coast on hype. In a hub, proximity to money and noise can carry a mediocre product further than it deserves. From the outside, none of that is available. The product has to be genuinely useful or it is nothing, because there is no scene to prop it up. That pressure makes for better products.

You build for the real world by default. The pristine, high budget, everything works environment is not the water you swim in. You are closer to constraints, to users who cannot tolerate fragility, to the ordinary conditions where most software actually has to run. That is not a handicap, it is the correct starting point.

And you learn to work across distance and difference, because you have to. Different languages, different markets, different time zones. That is not a limitation on the team, it is training for how the world actually works.

I am not romanticizing it. Being outside the hubs has real friction, less local capital, fewer people who have done it before, more that you have to figure out alone. But the idea that serious technology can only be built in a few zip codes belongs to the past. The tools are global now. The talent always was. The only thing still catching up is the assumption.

I build from Tetouan. The work speaks for itself.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.

Every AI feature is a new attack surface

issam fathi — Fri, 17 Jul 2026 19:12:00 +0000

Every time you add an AI feature, you add a door. Most teams are so focused on whether the feature works that they forget to ask who else can walk through it.

I sit across product and security, and the pattern I see is consistent. A team ships an AI capability, a model that answers questions, summarizes documents, or acts on user data, and treats it purely as a product win. Meanwhile it quietly became one of the softest parts of the system.

The reasons are not exotic. An AI feature usually takes untrusted input, often free text, and does something meaningful with it. That is the classic shape of a security problem. Prompt injection is just untrusted input reaching a powerful interpreter, the same category as the injection bugs we have fought for twenty years, wearing new clothes. If your model can call a tool, read a file, or hit an internal service, then whoever controls its input has a lever on your system.

So here is the discipline I try to hold.

Treat model input as hostile by default. The same way you never trust a form field, never trust what reaches the model, especially if the model can then act. The convenience of "just pass it through" is exactly where the hole is.

Constrain what the model can reach. A model that can only read the one document it was given is a small risk. A model wired into your internal tools with broad permissions is a large one. Scope its access like you scope a service account, least privilege, not most convenience.

Log what it does, not just what it says. When something goes wrong with an AI feature, you need to reconstruct the actions it took, not only the text it produced. If you cannot answer "what did the model actually do at 3am," you are flying blind.

None of this slows real products down. It is the same instinct that separates engineers who ship things that survive contact with the real world from those who ship demos. AI does not get a security exemption for being new and exciting. If anything, new and exciting is exactly when people stop checking the locks.

Build the feature. Then ask who else it just let in.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.

Building AI tools for people who don't trust AI

issam fathi — Fri, 17 Jul 2026 18:45:42 +0000

Most conversations about AI products assume the user is excited. They assume someone who wants the magic, who will forgive a rough edge because the technology is cool. In my world, that user does not exist.

I build for people who own buildings, roads, and infrastructure. Practical, experienced professionals who have watched a parade of software promise to change everything and then waste their time. When AI shows up, their first reaction is not excitement. It is suspicion. And they are right to be suspicious.

That changes how you have to build. When your user does not trust the technology, every easy shortcut becomes a landmine.

The first rule is that a confident wrong answer is worse than no answer. A skeptical user will forgive "I am not sure about this one, take a look." They will never forgive being told something false with total confidence, because the first time it happens you have lost them for good. So the product has to know the edge of its own knowledge and say so. Certainty you have not earned is not a feature, it is a liability.

The second rule is show your work. A number on a screen means nothing to someone who does not trust where it came from. Let them see the image, the evidence, the reason. Trust is not built by hiding the machinery, it is built by making the machinery inspectable. The goal is not to make the user believe the AI. It is to make the user able to check the AI in five seconds and move on.

The third rule is earn the next step. You do not get to automate someone's whole job on day one. You get to save them ten minutes on one annoying task. If that ten minutes is real, they come back, and the relationship grows from there. Skeptical users do not convert with a pitch. They convert with a small, repeated, undeniable win.

None of this is specific to buildings. Any time you put AI in front of someone whose profession predates the technology, whose reputation is on the line, and who has been burned before, the same rules apply. Be honest about uncertainty. Make yourself checkable. Earn trust in small pieces.

The irony is that building for the skeptic makes a better product for everyone. Honesty about limits, visible evidence, and value that compounds are not concessions to a hard audience. They are just what a good tool does.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.

The drone was never the hard part

issam fathi — Fri, 17 Jul 2026 18:45:41 +0000

When people picture a drone inspecting a building, they picture the flight. The aircraft rising up the facade, the camera sweeping across the roof, the pilot on the ground. It looks like the drone is the technology. It is not. The drone is the easy part.

I work on AssetEye, an AI platform that turns drone and 3D data into structured insight for the people who own buildings and infrastructure. The thing I keep relearning is that flying a drone over an asset was solved years ago. Anyone can capture thousands of images of a roof. The hard part starts the moment the drone lands.

Because a folder of five thousand photos is not an inspection. It is a problem. Somebody still has to look through all of it, decide what matters, find the crack that will cost real money next winter, and turn that into a decision the owner can act on. That is where the work actually lives, and that is where most of the value hides.

Here is the shift that matters. The question was never "can we see the asset." Drones answered that. The question is "can we understand it, at scale, without a human staring at every frame." That is a data problem and an AI problem, not a flying problem.

So when we build, we spend almost no time on the capture and almost all of it on what happens after. How do you take raw imagery and 3D geometry and surface the three things on this roof that need attention, out of the thousands that do not. How do you make that trustworthy enough that an owner will spend money based on it. How do you make it consistent, so the same defect gets flagged the same way on building one and building four hundred.

Get that right and the drone becomes almost boring, which is exactly what you want. The technology that matters is the layer that turns pixels into a decision. The flight is just how the pixels arrive.

There is a wider lesson here for anyone bringing new tech into an old industry. The flashy part, the part that looks futuristic in a demo, is usually the part that is already solved. The value is downstream, in the unglamorous work of turning capability into something a busy professional can trust and use. Chase the boring part. That is where the moat is.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.

Most companies don't have a technology problem. They have an adoption problem.

issam fathi — Fri, 17 Jul 2026 18:36:30 +0000

Every few months a company buys a powerful new tool, announces a transformation, and quietly goes back to the old way of working within a quarter. The software was fine. The rollout was the failure.

I see this from a specific seat. I am the product manager of AssetEye, an AI platform that turns drone and 3D data into structured insight, so the people who own buildings and infrastructure can actually see their cost, their risk, and their CO2 instead of guessing. The hard part of that work is almost never the model. The model works. The hard part is getting a traditional industry to trust it and fold it into how they already operate.

That gap, between a tool that works and a team that uses it, is where most transformation money dies. So here is how I think about closing it.

Build for the user's reality, not for the demo

A demo is designed to impress in five minutes. Real work is messy, interrupted, and done by people who did not ask for a new system. If your product only shines in the perfect case, you have built a trade show prop, not a tool. I would rather ship something that survives a bad day on site than something that dazzles in a boardroom.

Adapt the workflow, not just the tool

Dropping AI into a broken process gives you a faster broken process. The real question is never "where do we add the model," it is "what decision is this person trying to make, and what is slowing them down." Sometimes the answer is not more technology at all. Knowing that is the job.

Grow by winning one real problem first

Nobody adopts a platform because of its roadmap. They adopt it because it solved one painful, concrete thing this week. Prove value on a single problem the user actually feels, earn the trust, and expansion takes care of itself. Trying to transform everything at once is the fastest way to transform nothing.

None of this is about being anti technology. I love the technology. It is about respecting the distance between capability and use, because that distance is where every real result lives. Companies do not fall behind because they lack tools. They fall behind because they cannot get their people to trust and use the tools they already have.

Build for reality. Adapt the workflow. Grow from one real win. That is not a strategy deck. It is just what works.

I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.