Frequently asked questions

Not directly. The quote builder is a scoping tool: it captures your project brief in about 5 minutes (no price displayed). After that, we book a short call together where Oussema shares the tailored estimate based on what you submitted. This keeps the figure accurate, not a rough guess from a form.

Every project is different, so prices are personalized. The flow is simple: you fill the quote builder (about 5 minutes) to scope your needs, we get on a short call together, and I send you a tailored estimate right after. No commitment, no hidden fees.

A quote is built around three factors: the scope of the project (features and pages), the technical complexity (AI integration, automations, custom backend), and the timeline. The quote builder captures all of this upfront, then we go through it together on a short call before the final estimate is shared.

Payments are split into milestones, usually a kickoff deposit followed by payments at each major delivery. Bank transfers and most international payment methods are accepted. The full schedule is agreed before any work starts.

Yes, projects start with a deposit (typically 30 to 40 percent of the total). It secures your slot in the schedule and covers the kickoff phase. The remaining balance is paid in milestones as we progress.

No. The quote covers everything we agreed on. If anything outside that scope comes up later (new features, extra integrations), we discuss and price it separately before any work happens. No surprises.

Three. Fixed price for a defined scope with clear deliverables, which is what most projects use because it makes the budget predictable on both sides. A monthly retainer for ongoing maintenance, support or advisory work. Time and materials when the scope is genuinely open and you want to steer sprint by sprint. Whichever applies, the quote is written and approved before any work starts.

Through a written change order, before any new work starts. I document the new requirement, estimate its impact on the timeline, and send a revised price in USD. You approve it or you do not, and the agreed scope keeps running either way. Nothing gets built on a verbal request and billed as a surprise at the end, which is the single most common way a fixed price project turns sour.

It comes down to four things: how many questions it has to answer reliably, where the answers live (one clean document set is quick, five scattered tools is not), which systems it has to reach such as a CRM, WhatsApp or order data, and whether it needs an evaluation set and a security review before launch. Describe the bot in the quote builder, about five minutes, and you get a written quote after a short call instead of a number that ignores your context.

A scoped build, such as a chatbot answering from your documents or one automated workflow, usually runs four to eight weeks. A production agent touching several internal systems runs three to six months, most of it data access, integration and testing. A narrow MVP can ship in two weeks. The exact date comes out of the scoping call, because what really moves it is how reachable your data is.

As soon as the quote is validated and the deposit received. If my schedule is busy, you are told upfront so we plan a realistic start date together. We never begin until you have full visibility on the schedule.

Yes, when my schedule allows it. Rush projects come with a tighter daily rhythm and a small rush fee on top of the standard quote. Best move: mention the deadline early so feasibility can be confirmed.

A scoped integration, such as a chatbot answering from your documents or a single workflow automated by an ADK or Genkit agent, usually takes four to eight weeks. A production agent that touches several internal systems runs three to six months, and most of that is data access, integration and testing rather than model work. What really moves the date is how reachable your data is: if the content sits in one clean place the build can start in week one, and if it is spread across five tools the discovery phase grows accordingly.

Yes, if the scope stays narrow. Two weeks buys one clear problem, one data source and existing models rather than anything trained from scratch, on a stack that already runs in production (Next.js, Firebase, Genkit). That is enough to put a working product in front of real users and learn whether it deserves to be built properly. It is not enough for multi tenant billing, a full admin back office or a compliance review, and I will say so before accepting the deadline rather than after.

Four steps: kickoff (we align on goals, scope, and design direction), build (iterative sprints with regular previews), review (you test, give feedback, we polish), and launch (deployment, training if needed, handover). You have visibility at every step.

A shared channel (WhatsApp, Slack, or email, your choice) is used for daily messages, plus a weekly sync of about 30 minutes to review progress and decisions. Async first, calls when needed.

Revisions are built into the process: at each sprint or milestone, you give feedback and we iterate until the deliverable matches what we agreed. No artificial cap. Large scope changes (new features, redirection) are scoped separately.

It rarely happens because you see and validate at every step (design, build, polish). If something is off, it gets identified early and adjusted. The iterative process avoids the all or nothing final reveal.

Then I work under your CTO, not around them. A CTO usually has the architecture and the product context but a finite number of hours, plus specific gaps that tend to sit on the AI and automation side. I take one bounded piece (an agent, a data pipeline, an integration, a rescue) and deliver it inside your existing repository, branch conventions and code review process. Your CTO keeps ownership and technical oversight, and the deadline still gets met.

Hiring VAIIBE makes sense when the system has to ship now and you cannot spend three to six months recruiting, onboarding and paying a full time salary before the first release. You get one senior engineer who already runs the stack in production (Next.js, Firebase, Google ADK, Genkit, LangChain, LangGraph, n8n) and who covers architecture, build and deployment without a handover in the middle. An in house hire is the better call once the product is stable and the work turns into continuous maintenance of a system you already own.

Five areas. Custom SaaS plus web and mobile apps on Next.js and Firebase. AI agents and chatbots built with Firebase Genkit and Google ADK, including retrieval over your own documents. Custom automation with AI agents on Google ADK, Genkit, LangChain and LangGraph, from app to app plumbing up to autonomous workflows, with n8n when a low code tool is the better fit. E-commerce and marketplaces. And advisory work: SEO and GEO audits, rescuing AI generated codebases, and technical mentoring.

Yes. Cross platform (React Native or Flutter) is the default option because it ships faster and covers both stores. Native development stays available when a project really needs it. The right approach is discussed together during the scoping call.

Yes, AI integration is a core service. Common use cases: a chatbot trained on your data, content or document generation, search and recommendations, automation of repetitive tasks. We start with a quick audit to identify where AI brings real value, not just buzz.

Mainly Next.js and React on the frontend, Node and Firebase or custom backends on the server, Tailwind for styling, and tools like Genkit or OpenAI for AI features. Stack choice is always driven by what fits your project best, not by trend.

Google ADK, Genkit, LangChain and LangGraph, picked per project rather than by habit. Genkit handles model orchestration, structured output and evaluation inside a TypeScript application. ADK carries agents that need tools, memory and a longer running loop. LangGraph suits branching workflows that hold state. n8n stays for simple glue between existing SaaS tools. The choice is written down during scoping, so you know what runs your product and why.

Whichever model fits the task and the budget, not a single favourite. Most production flows run on a small fast model, because it answers in about a second and keeps the monthly bill low. Heavier reasoning or long documents move up a tier only where the quality gain is visible in the evaluation set. The provider sits behind one interface in the code, so a model change is a setting rather than a rewrite.

Yes, and the code is written for it from the first day. Calls to the model go through one adapter, prompts and evaluation sets live in your repository, and nothing provider specific leaks into the business logic. Switching then means changing a setting and re running the evaluation set to confirm the quality held. Prices and model quality move every few months, so being locked to one vendor is how a working feature turns expensive.

Yes. Projects run on Google Cloud and Firebase, where the database and storage region is pinned when the project is created, so your data can stay in the European Union, the United States or another supported region. Hosting is billed by Google to your own account, which keeps you in control and lets you take everything with you. If you would rather host elsewhere, the stack is standard Next.js and containers, so it moves.

I keep a strict separation between my development environments and your production systems. Data is encrypted in transit and at rest with standard protocols such as AES 256, and access follows a zero trust model where every request is authenticated and authorised. Because one engineer builds and operates your project, the list of people who can reach your data is one name long, and I review access, secrets and dependencies before every release.

Wherever your regulator and your users require. Projects run on Google Cloud and Firebase, where the database and storage region is pinned at creation time, so data can stay inside the European Union, the United States or another supported region. You get the exact region and service list at handover, so a compliance officer can map the data flows without asking me. If data residency is a hard constraint, it needs to be decided in the first scoping call, because moving a live Firestore database between regions is expensive.

Yes. Any project touching European Union personal data is built to honour the GDPR rights that matter in practice: access, rectification, erasure and portability. I sign a data processing agreement that names you as the controller and me as the processor, document what is stored and where, and keep every third party processor listed (hosting, model providers, email, analytics) so your own compliance file stays accurate instead of guessing at the stack.

Yes, routinely, and before you share anything sensitive. A good NDA covers both the build phase and the period after handover. Make sure it names the data, the prompts and the business logic, not only the source code, because on an AI project the prompts and the evaluation set often carry more of the competitive advantage than the code does. Send yours and I will sign it, or ask and I will send a standard mutual one.

You do. Every contract I sign assigns the source code, the documentation and the architecture to your company on payment, and the repository lives in your organisation from the first commit rather than in mine. More generally, ownership depends entirely on the contract signed before work begins: when an agreement is silent on IP assignment, the builder can keep the underlying code and grant you only a limited licence. Insist on an explicit clause transferring copyrights, patents and trade secrets to your company, whoever you end up hiring.

Every launch comes with a 30 day warranty covering anything that does not behave as agreed, at no extra cost. After that, a monthly maintenance plan covers uptime and error monitoring, dependency and security updates, provider side model and API changes, and small evolutions. For AI features I also watch answer quality and latency rather than server health alone, because a chatbot can be perfectly available and still be confidently wrong.

Yes, and it stays optional. Every launch includes a 30 day warranty for anything that does not behave as agreed. After that you can take a monthly plan covering uptime and error monitoring, dependency and security updates, provider side model changes and small evolutions, or pay per intervention. Running costs such as hosting and model usage are separate and stay in your own accounts, so the product can stay live without any plan.

Bugs related to what we built are fixed for free during the warranty window (typically 30 days after launch). After that, fixes are covered by the maintenance plan or billed per intervention. Either way, response is fast.

Yes. Every project includes a 30 day warranty starting from launch. Anything that does not behave as we agreed gets fixed at no cost during that window. Beyond that, maintenance plans take over.

Yes. Small changes and fixes are covered by the monthly maintenance plan, which is the cheapest way to keep a live product moving. Anything that changes the architecture, adds an integration or alters how an AI feature behaves is scoped as its own small fixed price project, so you know what a change costs before it starts. For AI features I re run the evaluation set after every prompt or model change, because a change that looks harmless can quietly move accuracy in the wrong direction.

Three lines, billed by the providers straight to your own accounts rather than through me: hosting, which stays low because the stack scales to zero when nobody is using it; model usage, which follows the number of conversations and the length of each answer; and storage for your data and files. I size those with you before the build and pick the smaller model wherever it does the job, so the running cost stays proportional to real usage instead of arriving as a fixed monthly surprise.

Tunisia, but I work remotely with clients across Europe, North Africa, and the Middle East. Timezone overlap with Europe makes daily collaboration easy.

Three working languages: English, French, and Arabic (including Tunisian Darija). Project documentation, calls, and deliverables can be in any of them, or mixed if your team is multilingual.

Fully remote by default, that is how all my projects run today. On site visits remain possible in Tunisia or Europe for a kickoff or workshop, with travel costs covered by the client.

I work with clients in Tunisia, the wider MENA region, Europe and the United States. Being based in Tunisia means the working day overlaps almost entirely with European business hours and covers a solid part of the American morning, and projects run in English, French or Arabic depending on what you prefer. Delivery is remote by default, so what actually matters is the timezone overlap and the language you want to work in, not the distance.