frequently asked questions

We give you a real number, not a guess. A stabilization sprint and codebase review runs 1-2 weeks. A focused MVP (minimum viable product) runs 4-10 weeks. For rescue work we quote after a short paid review, because we will not put a date on a codebase we have not read yet. We reply to new inquiries within 1 business day, and once we start you see working software every few days.

By whether the software still works after we leave. We track four things: did it ship, is it stable in production (crash rate, error rate, uptime), can your team maintain it without us, and did it move the number you care about, revenue, retention, or rating. We agree those measures before we start, so the result is something we both defined up front.

We do our best work with people who want a straight answer more than a comfortable one. The projects we take on are the ones where a mistake costs real money or real users: a launch with a fixed date and a payment flow that has to clear money on day one, or an app whose original developer is gone and left no one who understands how it works. What we ask of a client is clarity about what they need and the trust to let a senior partner run it.

We understand before we touch anything. For a new codebase that means reading it, mapping how it works, and finding where it is fragile before we propose a single change. We fix root causes, not symptoms. We validate at the real boundaries, user input and external APIs, and ship in small, reversible steps, so you are never one big change away from disaster. When something is genuinely uncertain, we say so and test it rather than guess in production.

Our AI work goes well beyond using Claude Code. We build custom agents and subagents, wire them into our pipelines with hooks, and put evals and guardrails around them so the output holds up in production. That is how one engineer does what an agency staffs as a four-to-six-person team, and can ship in weeks rather than the months they would quote. Here is what most "we want AI" clients miss: anyone can paste a prompt into an AI tool and get a working-looking prototype by Friday. Getting that same thing to survive real users, real data, and an app-store review is the part that still takes an engineer. We use AI to move faster, and we never ship what we have not understood.

In clearly scoped engagements, not open-ended hourly billing. Most work is fixed-scope: a build, an MVP, or a defined piece of work, with the price and deliverables agreed before we start. For ongoing work we offer a retainer. Rescue jobs start with a short paid review, so the estimate is based on your actual codebase. You always know what you are paying for up front. We would rather quote honestly and lose the deal than surprise you with an invoice.

Yes. Beyond fixed-scope projects we take retainers: a set amount of senior engineering each month for ongoing builds, maintenance, or a product that needs a steady hand. It suits teams that need principal-level help but not a full-time hire. We agree the scope and the monthly commitment up front, and you can scale it up or down as the work changes.

Three things. First, the senior engineer who quotes your project is the one who writes the code; there is no junior swap after the sales call. Second, you get senior ownership without agency overhead: one accountable person, backed by trusted collaborators when scale demands it. Third, the work is provable: our open-source contributions are merged into projects like Tiled, JetBrains, and Mozilla Thunderbird, so you can see how we build before you hire us.

It starts with you telling us what you want to build, or what is going wrong. We reply within 1 business day. If it looks like a fit, we scope a small first step, usually a review or a short sprint, so you can judge us before committing to anything large. From there we work in visible increments with regular check-ins, and you own all the code and accounts throughout. If at any point it is not working, you are not locked in. We would rather earn the next phase than trap you in the current one.

Yes. We work under NDA routinely and treat your code, data, and plans as confidential by default, signed or not. We keep credentials in proper secret management, never hardcode them, and never reuse your material elsewhere. Send us your NDA and we will sign before the first call, or if you do not have one, we can draft a simple mutual NDA to start from.

It depends on what you are building. For maximum performance and platform features, native Swift (iOS) and Kotlin (Android) win. To share one codebase across both stores, Flutter and React Native are strong. Kotlin Multiplatform (KMP) shares business logic while keeping native UI, a good middle path for teams that already have native apps. If you are unsure which fits, that is exactly the call we help clients make.

A focused MVP usually lands in the $15k-$40k range and takes 4-10 weeks, depending on how many real features it needs and how clearly they are defined. The fastest way to blow the budget is a fuzzy scope, so the first step is pinning down the smallest version that proves your idea, then building exactly that. The result is a small product real users can actually use, and that holds up when they hit it.

A simple app starts around $10k-$30k. A mid-complexity app with a backend, auth, and integrations runs $30k-$100k. Apps with real-time features, custom infrastructure, or regulatory requirements go higher. Cost is driven less by the length of the feature list than by how clearly the requirements are defined before anyone writes code, which is why we scope hard before we quote.

We start by reading, not rewriting. In a short paid review we map how the app works, find where it is fragile, and separate the quick wins from the deep problems. Then we stabilize first, stop the bleeding and get it shippable, and modernize second, in small reversible steps. A full rewrite is the last resort, because most stalled apps can be saved for a fraction of the cost of starting over.

Usually refactor, sometimes rewrite, and the honest answer needs a look first. If the core still earns its keep and the problems are localized, we modernize in place: pay down the worst debt, add tests, update the risky dependencies, and put a sane pipeline around it. We recommend a rewrite only when the foundation genuinely cannot carry where you are going, and even then we do it in slices, so you are never offline waiting for a big launch.

It is a common moment: a product is built in Bubble or FlutterFlow, finds traction, then hits the platform's ceiling. We start by getting your data out cleanly and mapping what the no-code app does. FlutterFlow exports real Flutter you can build on; most others need a rebuild, which we do feature by feature so you keep running the whole time. We also build the new version with an exit in mind, so you are never that locked in again.

Pick the tool to the job. Webflow is great for marketing sites with design control, Softr and Retool spin up internal tools and portals from your data, and Bubble handles full apps with real logic. They are excellent for an MVP or internal use. The catch is the ceiling: once requirements get specific you slow down, and moving off later can hurt, so choose one that lets you export or extend.

For mobile, FlutterFlow exports real Flutter code, so you are not trapped. Glide is the quickest for simple data-driven apps. For internal dashboards, Retool and Streamlit (if your team writes a little Python) are hard to beat. No-code is genuinely fast for prototypes and internal tools, and rarely fast for a polished, scalable product, so know which one you are building before you commit.

Match the tool to the outcome. Webflow for a marketing site, Shopify for selling products, Softr or Glide for a customer or member portal, Microsoft Power Apps if you already live in the Microsoft stack, and Bubble when you need real custom logic. Each is a fine starting point. Once your logic, compliance, or scale outgrows the platform, you will need a developer. That usually happens sooner than teams expect.

If you want to learn real development, start with Flutter or React Native; both have large communities and solid documentation. If you want results without writing code, try FlutterFlow or Adalo. Pick one and stick with it long enough to finish a real project. That is where the learning actually happens.

Almost all of them have a free tier. FlutterFlow, Glide, and Bubble let you start building for free, the code tools (Xcode, Android Studio, VS Code) are free outright, and backends like Supabase and Firebase are free up to a generous limit. The real expense is the time it takes to learn one well enough to ship with it.

You need a paid developer account (Apple $99 a year, Google $25 once), and then you face the review against Apple's App Review Guidelines and Google Play's policies. Apple is strict and can reject for things you would not expect; Google is faster but still enforces real policy. The part teams underestimate is the metadata: screenshots in multiple sizes, an app preview, a localized description, a privacy policy, data-safety and tracking disclosures, age ratings, and AI-content declarations, all correct or you get bounced. We have published many apps through both stores and handle it end to end, including the back-and-forth with reviewers when a build gets flagged.

Shopify is the default for selling products. WooCommerce on WordPress if you want to self-host and avoid per-sale platform fees. For a more custom storefront, a Django or Node backend with Stripe gives you full control over pricing, checkout, and data. For a native mobile shopping experience with custom logic, a developer saves you months of fighting platform limits.

Stripe and PayPal are the most developer-friendly, with SDKs for iOS, Android, and web, and Apple Pay and Google Pay make mobile checkout one tap. The integration itself is routine for a developer. The work that takes experience is the rest: failed and disputed payments, refunds, taxes, and compliance. Get those right, and money never goes missing and your books stay clean.

Vercel and Netlify are excellent for web apps and static sites. AWS, Google Cloud, and Azure handle everything but bring complexity. For most startups, a managed platform like Vercel, Railway, or Render gives you 90% of what you need without the DevOps overhead. Pick based on your stack, not the brand name.

More than most teams expect, and it is increasingly the law: the EU Accessibility Act applies from June 2025, and US ADA cases keep rising. The baseline is WCAG 2.2 Level AA: proper labels and contrast, full keyboard and screen-reader support (VoiceOver on iOS, TalkBack on Android), and content that does not break when text is enlarged. It is far cheaper built in from day 1 than bolted on after a complaint, and we test with the actual screen readers your users rely on, on real devices.

Yes, and remote is the norm now. The best team for your build is rarely the one nearest you; it is the one with the right experience that communicates clearly and ships. We keep overlapping hours across time zones, so you are not waiting a day for an answer. You own the code and accounts from day 1, and the work lands in your repository continuously, so you are never dependent on one person's availability.

Look past the star rating; a review is about someone else's project, not yours. Ask to see apps they shipped that are still live and maintained, and make sure the person you talk to is the person who will actually write your code. With a one-person studio that is automatic: the founder is the engineer.