Skip to content
Ayoub
Software engineer · technical partner

You have the idea.I build the rest.

From studying your market to the day real people sign up.For founders with an idea and no technical team.

It starts with one conversation, about thirty minutes - by call or in writing.

What you’re signing up for

You approve each stage before the next one starts.

Every stage ends with something you can open and judge for yourself.

In your name
The code, the accounts and the domain are yours. You can take them to anyone.
Straight to me
You write to me and I answer. There is no account manager in between.
After launch
Launch is not the finish line. I stay through the first real users and the first things that need fixing.
Taking on new projectsFirst reply within one business day

The short version

You do not need to write a spec, choose a technology, or know what an API is. That is the job you are hiring me for.

What happens instead

Instead of a spec
We talk it through. I write down what I heard and send it back, and you correct it until it says what you meant.
Instead of choosing a stack
I choose, and I write down why in one sentence you can hold me to later. You are never asked to arbitrate a decision you have no way to judge.
Instead of learning the words
You judge the product on the screen, not the code behind it. When I need a decision from you, I ask for it in plain language.
Where most people are when they find me

The idea is fine. The next step is the problem.

You have had the idea for months. You asked two developers and got two different numbers and no explanation. You do not know what to build first, what it should cost, or how to tell whether the work is any good. So it is still an idea.

That is the gap I work in.

Idea to launch

Six stages. You always know which one you are in.

Every stage says what I need from you, what I handle, and what exists when it ends. Nothing starts before you have seen and approved what came before.

Understand it

You tell me the idea

A single conversation, usually about thirty minutes.

We talk until I can describe your idea back to you correctly.

What you have at the endA written idea brief: the goal, the user, the assumptions, and what success means.

You see the market gaps

Usually a few days to a week.

I find out what already exists and where it leaves people stuck.

What you have at the endA market and competitor report, with the gaps ranked and the evidence linked.

Shape it

You see the real screens

Usually a week or two.

We decide what the product is, and you see it before it is built.

What you have at the endA clickable prototype of the main screens, plus the agreed feature list.

You approve the plan

Usually a few days.

The build gets broken into phases, each with its own scope and price.

What you have at the endA phase plan: scope, price and result for each phase, in writing.

Build it

You watch it being built

The longest stage. Weeks to months, depending on scope.

The product gets built in order, and you see it working every week.

What you have at the endA working product on a live link, updated every week, with the code in a repository you own.

Launch it, and stay

You launch, and I stay

Launch takes days. Staying afterwards is ongoing.

The product goes live, and I stay until it is genuinely right.

What you have at the endThe live product on your domain, with accounts, code and a short handover guide.

See all six stages in full
Who does what

Your side of this is small on purpose.

You bring

  • The idea, in your own words
  • Who it is for
  • A decision when I ask for one
  • What you can afford to spend
  • A couple of hours a week

I bring

  • The market and competitor read
  • What to build first, and what to cut
  • The design and the screens
  • The code, the database, the hosting
  • The launch
  • The person who fixes it when it breaks

If a question needs technical knowledge to answer, it is my question, not yours.

What usually goes wrong

The reasons people hesitate, and what I do about each one.

I’ll pay, and months later get something I never pictured.
You see and approve clickable screens before I write the code behind them.
It will cost more than I was told.
Each phase is scoped and priced before it starts. You approve the number before any work happens.
They will use words I don’t understand.
I don’t. Ask me the same question twice if you need to; that is a normal part of this.
They will disappear the day it launches.
Launch is stage six of six, not the end. I stay until the product is genuinely right.
I don’t know enough to tell if the work is good.
You get something working on a real link every week. You judge the product, not the code.
My idea is not big enough to be worth building.
Tell me on the first call. If it is not worth building yet, I will say so instead of taking the work.
What I build

SaaS is my deepest work. It is not the limit.

The method below is the same whatever the product. What changes is how much of it a given product needs.

SaaS Platforms

A subscription product founders can sell, from first idea to paying users.

A web product people sign up for and pay for every month. I handle the idea, the market study, the build and the launch. You stay the founder, not the project manager.

See how I work

Websites and Landing Pages

The public face of your business, built to load fast and be found.

The site people open before they decide to trust you. I set the structure, build the pages, and make sure search engines and phones both read it properly.

See how I work

Mobile Apps

An app on the phone, for the work that does not belong in a browser.

An app people install and open every day. I build the screens, the account system and the server behind them, then take it through the store review.

See how I work

AI Tools and Chatbots

An assistant that answers from your own material, not from guesswork.

A chatbot or an AI feature built on your own documents and data. It answers in your customers’ languages, says when it does not know, and hands hard cases to a person.

See how I work

Internal Tools

One tool for one problem, built to replace the spreadsheet you outgrew.

Software for your own team, not for the public. I map how the work is done today, then build the smallest tool that removes the manual steps.

See how I work
Selected work

What I built, and why it is the way it is.

Each one is written as a story: what the client was dealing with, the decisions I made, and what I gave up to make them.

Live2025

Assessment platform

An exam platform the institute runs itself, from question bank to results.

An institute had to examine its final-year students and rank them for prizes. I built the platform that ran and marked those exams.

Next.js · React · TypeScript · PostgreSQL · Prisma · Auth.js

Read the full story
LiveMy own project2025

Hiring platform

A marketplace where hiring and freelance work run on the same four steps.

Hiring sites and freelance sites are built as two different businesses. They are not, so I built the hard part once, for both.

Next.js · React · TypeScript · PostgreSQL · Prisma · Neon

Read the full story
LiveMy own project

Smart booking platform

Booking for beauty centres: WhatsApp at the front, a full system behind it.

Messages arrive at all hours. The platform answers for the centre, in the client's language, and turns questions into bookings.

Next.js · TypeScript · Prisma · Neon · Better Auth · WhatsApp Business API

Read the full story
See all work
Inside the build

Four lenses, in this order, on every phase.

Stage five is where most of the time goes. Every phase inside it is planned against the same four things, in the same order.

  1. 01

    Speed

    Get something real in front of people quickly.

    Ship the thinnest vertical slice that exercises the whole path: data model, server action, UI, and the real deployment. A slice that runs in production surfaces the wrong assumption in week one instead of week nine.

  2. 02

    Efficiency

    Build it so the next change is cheap.

    One source of truth per concept, typed end to end, with the data shape driving the interface rather than the other way round. The measure is how much has to move when a requirement changes.

  3. 03

    Security

    Assume someone will try.

    Authorisation checked at the boundary that actually writes, never only where the page renders. Input validated on the server whatever the client did. Secrets out of the codebase, permissions least-privilege by default.

  4. 04

    Cost

    Keep the monthly bill small and predictable.

    Managed services with a real free tier while usage is small, caching in front of anything read far more than it is written, and background work moved off the request path. Cost is a design constraint, not a surprise.

What this costs

Tell me the budget first, not last.

Most people expect it the other way round: describe everything you want, then wait for a number. That is how projects go over budget. I do it in reverse. You tell me what this is worth to you, and I design the largest useful version that fits inside it.

If your budget cannot buy something worth launching, I will tell you on the first call instead of taking the money.

What moves the number

  • How many different kinds of user the product has
  • Whether it takes payments, and in which countries
  • Whether it has to talk to systems you already use
  • Whether it needs to work in more than one language

What I don’t take on

  • Work I would have to pretend to understand
  • A rebuild of a codebase I am not allowed to read first
  • A launch date somebody else already promised

Ranges, not quotes. You get a number in writing for a phase before that phase starts.

Ayoub Hayda
Who you are dealing with

One person, and you talk to him.

I am Ayoub Hayda, a software engineer. I work as the technical partner for founders who have an idea and no technical team behind them.

Most of my work is SaaS products. That is where I go deepest. I also build websites, mobile apps, chatbots and AI tools, and small custom tools made for one specific problem.

Check everything here

Nothing on this site asks to be taken on trust.

There are no testimonials here, because I would rather show you things you can check than quotes you cannot. Where a product is public you can open it and use it. Where it is not - an internal tool, a client system - the case study says so, and shows the decisions instead. I will connect you with a reference on request.

Public products
Open the ones that are public
The trade-offs
Named in every case study, not smoothed over
A real person
Named, reachable, one inbox
References
On request
Before you ask

The questions people actually open with.

What if I only have an idea and nothing else?
That is the normal starting point. Most people who write to me have a sentence, not a plan. I ask questions until I can describe your idea back to you correctly. Then I study the market and tell you what is worth building first. You do not need a document, a budget breakdown, or a drawing of the screens. One or two lines is enough to begin.
Do I need to understand any of the technical side?
No. You decide what the product should do and who it is for. I decide how it is built. When a technical choice changes your cost or what you can offer your customers, I bring it to you in plain language with the trade-off written out. You will never be asked to approve something you do not understand.
What if I change my mind halfway through?
That happens on most projects, and it is usually a good sign. The build is split into phases, so a change lands at a phase boundary rather than in the middle of everything. A change gets scoped and priced before it starts, like any other work. Nothing is quietly absorbed and nothing is quietly dropped.
How does pricing work?
Budget first, not scope first. You tell me what you can spend. I design a product that fits inside it, and I say clearly what will not fit. Each phase is scoped and priced before it starts, so you approve one piece at a time. You are never committed to the whole build on the first day.
Who owns the code and the accounts?
You do. This is how I work: the repository, the database, the domain, the hosting and the payment accounts are created in your name where possible, or transferred to you. Nothing important sits in an account only I can open. If we stop working together tomorrow, you keep everything that exists and you can hand it to anyone.
What happens after launch?
Launch day is not the end of the work. I stay with you until the product is genuinely right. That means watching how real people use it, fixing what breaks, and changing what is confusing them. The first weeks after launch teach you more about your product than the months before it. I would rather be there for them.
What if I already started with another developer?
That is common, and it is fine. I read what exists first, then tell you honestly whether it is worth continuing or worth restarting, and why. Sometimes the right answer is to keep most of it. I will not recommend throwing away work just because I did not write it. You get the reasoning either way.
What do you build with, and why?
Next.js and TypeScript, with Prisma over PostgreSQL on Neon, and Tailwind with shadcn/ui for the interface. TypeScript catches whole classes of mistakes before anyone sees them. Prisma keeps the database schema in one readable place. Then Stripe or Lemon Squeezy for payments, Resend for email, Inngest for background jobs. These are boring, well-documented choices, and another developer can pick them up after me.
How do you handle security?
Validation happens at the boundary that writes, on the server, not only in the form the user sees. Authorisation is checked where data is read or changed, never only by hiding a button in the interface. Secrets live in environment configuration, outside the repository. Every key and database role gets the narrowest permissions that still work. Arcjet handles rate limiting and bot traffic at the edge.
Are you one person?
Yes. One person, one inbox, no account manager between us. Nothing gets lost being passed around, and the person who studied your market is the person writing the code. The limit is honest: I work on a small number of projects at a time. If I cannot give yours proper attention, I will say so before we start.
Can we work in Arabic?
Yes. Arabic, French and English, whichever you are more comfortable thinking in. Calls, messages, and every document I write for you can be in Arabic. I also build interfaces that work properly in Arabic, right to left, rather than an English layout with translated words dropped into it.
What do you not take on?
Work I could not do well. I turn down projects where the budget and the expectation are far apart, and ones whose timeline only works if nothing goes wrong. I turn down work that really needs a full team rather than one engineer. And I will not learn a whole new field on your budget. If it is not a fit, I will say so early.
Next step

Tell me the idea. That is genuinely all you need.

One or two lines is plenty. “I have an idea but I don’t know where to start” is a perfectly good message.

What happens after you send this

  1. You send thisTakes about thirty seconds.
  2. I message you on WhatsAppWithin one business day.
  3. We talk for about thirty minutesIn English, French or Arabic, whichever you prefer.
  4. You get a short written readThe closest competitors, what to build first, and roughly what it costs. Yours to keep either way.
Already know your scope and budget? Send a full brief instead.

Everything is required unless it says optional.

This is where I reply. I message, I don’t call unless you ask me to, and I don’t add you to any list.

Where I send the copy of this.

One or two lines is plenty. “I have an idea but I don’t know where to start” is a perfectly good answer.

Reply to me in
  • Free, and there is no obligation.
  • I reply within one business day.
  • Your idea stays between us. I don’t share it and I don’t reuse it.