Questions, answered

Yes. Everything runs remotely, so where you are does not matter: the brief, the updates and an early link you can click all travel over WhatsApp and email.

One developer. Every project on this site was built solo, end to end, and every message reaches me directly.

Dhaka, UTC+6. Every message reaches me directly, and I answer it myself.

You do. The code and the accounts are in your name, and you get handover notes so another developer can carry on.

Send a short brief: what you are building, what already exists and when you need it working. WhatsApp reaches me fastest; email or the contact form work too.

It depends on scope more than anything else. A focused first version that does one job well can ship far sooner than a full product with an admin side, payments and several integrations. Ask for the date of the first clickable milestone rather than a single finish date.

An agency gives you a team and a project manager. A freelancer gives you direct contact with the person writing the code, usually at a lower cost. For a first version with a clear scope, a strong freelancer is often the faster route. For a large system with several streams of work running in parallel, an agency may fit better.

Not to build a first version. Many products start with a freelance build that proves the idea. What matters is that you own the code and the accounts, so a future technical co-founder or in-house team can pick it up without starting again.

Yes. Remote work with clients in North America, Europe and elsewhere is common, and the time difference can be turned into an overnight work cycle.

Start small: a paid first milestone that ends in something you can try. It tells you more about working together than any interview.

No. Freelancers work with international clients directly or through marketplaces, under a simple written agreement.

Every project gets a fixed quote after a short brief, before any work starts. Starting prices: Website from $1,000; Mobile app from $3,000; Shopify app from $2,000; Marketplace & e-commerce apps from $2,500.

In milestones, in US dollars. Each payment is tied to something you can open and try: a working screen, a clickable flow or a deployed page.

They are starting prices for the scope listed. Send a short brief and you get a fixed quote before any work starts, so the price does not move halfway through.

Yes. The MVP is built to be extended, and you pay for the new scope when you need it.

AI agents, WhatsApp and Telegram bots, or anything custom: send a brief with what you are building and you get a quote for it.

Mobile app plans start at $3,000 for an MVP, $6,000 for a first full release with accounts and a backend, and $10,000 for apps that work offline, take payments or use AI. Every project gets a fixed quote after a short brief.

Website plans start at $1,000 for a landing page or small site, $2,500 for a business site with a blog, and $5,000 for a web app with accounts and dashboards. Every project gets a fixed quote after a short brief.

Marketplace automation starts at $2,500 for one automation on one marketplace, $5,500 to keep several channels in sync, and $9,500 for a tool built around how your business runs. A custom Shopify app starts at $2,000. Every project gets a fixed quote after a short brief.

With a cross-platform framework, building for both from the start usually costs only a little more than building for one, because most of the code is shared. If you must choose one, pick the platform your target users actually carry.

Because simple to use is not the same as simple to build. A single tap that "just works" often hides validation, sync, error handling and an admin view behind it. The simplicity your users feel is something someone had to build.

Sometimes, and for testing an idea it can be a smart first step. No-code tools get harder once you need custom logic, offline support, complex permissions or full control of your data. Many products start on no-code and move to custom code once the idea is proven.

Yes. FeedSeek and Clearday each have a phone app and a backend I built, and SplitMate has the app and its marketing site. Every project on this site was built solo, end to end.

Yes. iOS and Android come from one codebase, in React Native or Flutter, so you are not paying for two separate apps.

Both build iOS and Android apps from one codebase, and I have shipped apps in both. The React Native vs Flutter guide on the blog compares them and says when each fits.

Most apps with accounts or shared data do. The MVP plan includes a simple backend or a connection to an API you already have; the Flexible plan includes a Node.js API and database built for the app.

Yes. Help publishing to the App Store and Google Play is part of every mobile app plan.

You can, but it means rebuilding the interface layer, so it is not cheap. The backend, the data model and the API usually survive a switch untouched, which is one more reason to keep the business logic on the server rather than in the app.

Neither is reliably cheaper. The cost difference comes from the developer's experience with the framework and the shape of your app far more than from the framework itself.

Both. AI features almost always run on a server — your app sends a request and shows the result — so the framework barely matters. What matters is how the AI part is designed: fallbacks, cost control and letting users check the output. I covered that in integrating AI into your app.

As short as the one job allows. If the plan stretches over many months, the scope is probably too big. Cut until the first release is close enough to feel urgent.

No. Any new product or feature benefits from the same approach, including internal tools, Shopify apps and AI features added to an existing business.

Sometimes, for testing an idea. Once you need custom logic, offline support or full control of your data, custom code usually becomes the better choice. What drives the cost of an app covers that trade-off.

On the Flexible plan and above, yes: pages and posts you can update yourself.

Every plan includes the search basics: titles, descriptions, a sitemap and share previews, and the Flexible plan adds structured data and speed tuning. Rankings themselves take time and depend on your content and on other sites linking to yours, so no one can honestly promise them.

A website mostly shows information. A web app has users who sign in and do things: dashboards, admin screens and your own data, with a database and API behind it.

Yes. Every site goes live on your own domain, and the accounts are in your name.

Yes. FrameRx, a prescription-lens app for eyewear stores, is the most recent, and two earlier Shopify apps are public on GitHub.

Yes: bulk product and price updates, stock and order updates that happen on their own, and data moved between Shopify and the other tools you use. When no app in the App Store does the job, I build a custom Shopify app.

Yes: rules that raise or lower bids based on how each keyword performs, search terms that spend without selling added as negative keywords, budgets checked so campaigns do not stop early or overspend, and scheduled reports on what changed.

Yes: listings created and updated in bulk, inventory and prices kept up to date, orders pulled out for fulfilment or accounting, and reports gathered on a schedule instead of downloaded by hand.

Yes, in either direction: listings copied across, stock kept in sync so nothing is oversold, and orders from both in one place.

Yes: products from Shopify published to TikTok Shop, stock and prices kept in sync, and TikTok Shop orders brought back into Shopify to fulfil.

No. Custom apps and storefront features work on regular Shopify plans. Some checkout customisations are limited to Shopify Plus, so check early if your app needs to change the checkout itself.

Try existing apps first. If one does 90% of what you need, use it. Build custom when your process is genuinely different — like the lens rules in FrameRx — or when combining several apps creates more problems than it solves.

Yes. An app can call AI models from its backend, for example to read an uploaded document, describe products or answer shopper questions. The same care applies as anywhere: let people check what the AI produced. I covered this in integrating AI into your app.

Yes: an assistant that answers your customers and handles routine work, on your website, WhatsApp or Telegram, using OpenAI, Claude or Gemini. Anything that matters waits for a person on your team to approve it.

For most businesses, no. It takes the repetitive part of the work so your team can spend their time on the conversations that need a person. Designed well, it makes small teams feel bigger.

It can be, if the agent is built that way: limited tools, the minimum data sent to the model, no secrets in prompts, and the provider's business terms that cover how data is handled. Ask anyone building an agent for you exactly what data leaves your systems.

Modern models handle many languages well, including Bangla. Test with real messages your customers have sent, including the informal ones, before going live.

Often, yes, but the steps depend on how the number is used today and on Meta's current options. Decide this early, because the number becomes your identity on WhatsApp.

Not if you use the official platform, message people who opted in and keep your messages useful. Bans come from unofficial tools and spam.

Yes. A rules-based bot replies in whatever language you write its messages in, and an AI agent can understand and reply in many languages, including Bangla. Test with real customer messages, including the informal ones.

A simple alerts bot can be built quickly, because Telegram handles so much of the work. A customer-facing bot that connects to your order or booking system and includes an AI agent takes longer, mostly because of the integrations and the testing, not Telegram itself.

Telegram does not charge for the Bot API. You pay for hosting your bot's server and for any services it uses, such as an AI model.

Only people who have started your bot or joined your channel, and only within Telegram's rate limits. For announcements to a large audience, a channel is usually the better tool.

Start with whichever model does your first job best. Design the integration so adding a second provider later is easy. Once you have several distinct jobs, using the best model for each usually pays off.

Some smaller models can run on-device, which helps privacy and offline use. For most business features today, server-side calls to a provider remain the practical choice, with on-device models as an option for specific jobs.

The connection itself is quick. The time goes into the parts that make the feature trustworthy: structured output, an evaluation set, fallbacks, cost limits and a review step where it matters.