Common questions

Bluestone is a small software studio that builds web apps, internal tools, automations, and APIs for founders and businesses. We favor simple engineering, clear documentation, and engagements where the client owns the code, infrastructure, and IP. We are engineer-led and take on a small number of projects at a time so the work stays hands-on.

Eric is the founder and technical lead of Bluestone. He runs the engagement from the first call through handover — architecture, code review, and direct communication with you — rather than handing the project off to someone you've never met. If a specialist is needed for design, mobile, or a specific backend area, he brings in a trusted collaborator and stays on as the point of contact.

We are intentionally small. Eric leads every engagement, and we bring in trusted collaborators when a project needs design, specialized backend work, or other skills outside the core stack. You will not be passed around a large account team or handed to a junior developer we never introduced you to.

We are based in Canada and operate remotely. Most of our clients are in North America, but we work with founders and businesses in Europe and other time zones as well. Meetings happen over video, and we keep written records of decisions so time-zone gaps do not become communication gaps.

Yes. A large share of our clients are in the United States, and we work with teams across Europe and elsewhere. We invoice in CAD or USD, sign standard contracts in either jurisdiction, and work around your business hours wherever reasonable.

Most MVPs we build land between $15,000 and $40,000, depending on scope, integrations, and whether the work includes design. Smaller, single-purpose tools can come in under that range, and larger scopes with multiple integrations or complex data models can exceed it. We give a fixed quote after a discovery call — no open-ended billing.

For most new builds we charge a fixed project price tied to a defined scope, so you know the cost before we start. For ongoing work after launch, for maintenance, or for open-ended discovery, we offer monthly retainers. We rarely bill hourly — it rewards slow work and punishes good planning.

Typical projects run from about $5,000 for a small tool or automation to roughly $50,000 for a full product build with integrations. The average engagement sits in the $15,000 to $30,000 range. We do not take on engagements below a floor that would force us to cut corners on documentation, handover, or code quality.

Yes. After launch, many clients move to a monthly retainer for ongoing features, maintenance, and small requests. Retainers typically run between $3,000 and $8,000 per month, billed in advance, with a defined block of engineering time and a written scope of what is and is not included.

Yes. We ask for a 30 to 50 percent deposit to start, with the balance billed in milestones or on completion, depending on the project size. The deposit secures your slot on the calendar and covers the early discovery, architecture, and scaffolding work.

You do. All work product is assigned to you on payment — not licensed, not shared. This is written into our standard contract in plain language, and the practical setup matches: your GitHub organization, your cloud account, your domain, your third-party service accounts.

In your GitHub organization by default. If you prefer Bitbucket or GitLab, we use that instead. We are added as collaborators, not owners, and you can remove our access with two clicks when the engagement ends.

In your cloud account — typically Vercel, AWS, GCP, Supabase, or a combination, depending on the project. Every service is provisioned in your name and billed to you directly. You never have to ask us for access to your own production system, and your bills never flow through our company.

Nothing breaks. Because everything runs in your accounts, on mainstream platforms, using a standard stack, any competent engineer can pick the project up. The repo includes a runbook, an environment variable inventory, and a recorded walkthrough. That is the whole point of how we set up engagements.

Small tools and automations are often four to six weeks. A typical MVP takes eight to twelve weeks from kickoff to launch. Larger builds or projects that involve complex integrations can run longer, and we are honest about the timeline up front rather than compressing it to win the work.

Yes, and we do it often. We can join an existing codebase as an extra pair of hands, pair with your in-house engineer on a specific feature, or take a defined module end-to-end while your team continues on other work. We write documentation and open clean pull requests so your team can review what we did.

Yes. We are happy to sign a standard mutual NDA before any detailed discussion. If you have a template you prefer, send it over; if not, we can provide a short one.

We keep it simple: a weekly written update, a shared task board you can look at any time, and a short sync call when decisions are on the table. Eric is reachable by email and phone between calls. We do not run a Slack channel that pings you all day, and we do not go silent for a week and resurface with a demo.

We are engineer-led, and we bring in a trusted designer when the project needs one. For internal tools, dashboards, and API work we often use a lightweight component library and ship without a separate design phase. For customer-facing products and marketing sites, design is worth doing properly, and we budget for it.

Yes. We do takeover and rescue work regularly. We start with a short code review to understand the shape of what exists, flag risks and quick wins in writing, and then quote a scope to stabilize, document, and continue building. We are candid if a rewrite is actually cheaper than a rescue — that call is part of the review.

We use AI when it earns its place — not as a selling point. That usually means LLMs for summarization, classification, internal assistants, document extraction, and search, integrated into tools that would exist with or without AI. We don't bolt on AI features just to sound impressive, and we won't recommend an LLM where a SQL query is better.

We default to Next.js, React, and TypeScript on the front end; Node or Python on the back end; and Postgres for data, typically via Supabase or a managed provider. The stack is intentionally boring and reliable — widely used, well documented, and easy for any competent engineer to pick up after us.

For the size of company we work with, microservices usually cost more than they pay back — more deploys to manage, more places for bugs to hide, more infrastructure to own. We start with a single well-structured application and split it only when there is a concrete reason to. Simple scales further than most people expect.

Within reason, yes. If your team already runs Django, Rails, Laravel, or something else, we can work in that stack or extend it. If you have no constraint, we will recommend a stack we know we can hand off cleanly — that usually means the defaults above, because they are the easiest to hire for later.

We focus on web. For projects that need a mobile presence, we often recommend a responsive web app or a progressive web app first, and we partner with a specialist for native iOS and Android work when the project truly calls for it. We would rather point you to the right collaborator than fake a capability we do not specialize in.