Questions, answered.

A strong fit brings a fresh brief with room for an original idea, whether the work is visually bold, technically interesting, or both. Company or project size does not decide fit. Fit comes from the idea, room for craft, and the working relationship.

We take on focused websites, portfolios, campaigns, cultural projects, and digital experiments, among other kinds of projects. Project size is not the deciding factor; the idea and the room for craft are.

Yes. studio bauhaus very rarely joins an existing codebase, unless the work is part of a Scalable Dev Partnership. Fresh builds are preferred because they allow a coherent architecture, design system, and implementation from the start.

We review the brief, the creative or technical challenge, the timeline, the budget, the decision process, and whether we can give the project proper attention. Then we respond honestly before asking for a larger commitment.

Sometimes. It depends on our current capacity and the scope of the work, so raise your deadline early, in the first message.

We review it for fit, ask any follow-up questions we need to scope the project, and propose a next step, usually a discovery conversation.

Yes. studio bauhaus builds ecommerce websites by connecting the site to established services such as Stripe or Polar, other suitable commerce services, and custom integrations where needed. Proven services handle areas such as payments, tax, subscriptions, accounts, or fulfilment, rather than rebuilding every system from scratch.

Both. Our All-In-One (AIO) Service covers design and development. Project-Based Development is for projects where you supply the design. We scope and price each one-off project individually. For ongoing work, our Scalable Dev Partnership provides development through a retainer, with the scope and pace agreed for your team.

Yes. We can build from a design an agency or in-house team supplies, working directly to the file and specification you provide, as a development-only engagement.

Yes. We can join an agency or internal team on a project with a clear scope, deliverables, and timeline. White-label delivery is considered case by case.

It gives agencies or internal teams dependable ongoing development capacity across a series of projects. studio bauhaus works closely with the team, adapts to its workflow, and takes responsibility for agreed delivery. Scope and cadence are set in the retainer.

We can help shape content during design, but the client usually owns copywriting and final content. We agree responsibilities upfront in the proposal.

Clients with an existing brand supply their logo, colours, and fonts. If brand assets are incomplete, raise it during discovery so we can scope support or bring in a specialist if needed.

Yes. Motion is a core part of our craft, from scroll-driven transitions to interactive detail, always built to respect a visitor’s reduced-motion setting.

Our baseline target is WCAG 2.0 AA on every project. If your project needs a higher target, such as AAA or another required standard, tell us at the start so we can scope it in.

We target 100 in all four core Lighthouse categories on every project. Third-party scripts, embeds, analytics, hosting, or required functionality can constrain a perfect score. When that happens, we optimise what is in our control and explain the trade-off.

Responsive layouts are designed for the screen sizes each project needs, then tested across the browsers and devices agreed for that project.

Yes. We build custom interactive features, including 3D, animated maps, and timelines, when a project calls for them.

We choose the architecture around the project: its content, interactions, integrations, editing needs, performance targets, and long-term ownership. Static generation is our usual starting point, and we add services or a different architecture where the project genuinely needs one.

Static site generation creates complete pages before the site is deployed, so a visitor receives a ready page instead of waiting for a server to build one on each request. For most marketing and content sites, this improves speed, makes hosting simple and resilient, produces SEO-ready output by default, and reduces the server-side attack surface. We use server-side rendering only when live data or application behaviour genuinely requires it.

We no longer have a default CMS. The choice depends on the project: the editorial team, publishing frequency, permissions, and integrations all shape which content workflow fits best.

Yes. We can connect a new front end to an existing stack, third-party APIs, or company systems. Tell us what you already use so we can plan the integration.

We build with clean markup, fast pages, and correct metadata as standard. We do not promise specific rankings, since results depend on factors outside our control.

Yes. We can structure a site so search engines and AI systems can understand it, through semantic HTML, clear information architecture, crawlable content, metadata, and structured data. No studio can guarantee how an external search engine or model ranks, cites, or presents a site.

Yes. We set up analytics and cookie consent to match your privacy requirements and can work with tools you already use.

Our architecture and deployment choices follow current best practice to reduce risk: keeping unnecessary attack surface to a minimum, keeping secrets out of client-side code, and limiting the number of moving parts. Projects handling sensitive data or user accounts get additional review scoped to that need. No studio can promise the prevention of every possible issue.

Usually, yes. Access is agreed case by case, but most projects include repository access and a full source handover. Ownership, reuse, and any third-party licence terms are recorded in the proposal.

We start with a discovery conversation about your goals, timeline, and budget. From there, we prepare a proposal.

Yes. Every project starts with a written proposal covering scope, price, and schedule, so you know what you are agreeing to.

We quote a fixed price based on scope, not an hourly rate. We do not publish standard figures, since every project’s scope differs.

Payment is staged across the project, typically tied to milestones such as design approval and launch, rather than one lump sum.

Timing is confirmed once we understand scope, dependencies, your availability, and our current capacity. We agree a schedule in the proposal.

We build structured feedback rounds into each stage, so you review and comment before we move forward. Reasonable revisions are part of the agreed scope.

We discuss the change, then agree any adjustment to price or schedule before proceeding. We flag dependencies, such as third-party approvals, licences, or content from your side, early, and build them into the schedule.

We deploy through a standard, automated pipeline to modern hosting. We agree the exact provider with you before launch.

Either you or the studio can hold hosting and accounts, agreed per project. Ownership and access are documented before launch.

We hand over repository access, documentation, and any accounts agreed in the proposal, along with a walkthrough of the finished site.

Yes. We provide documentation on the build and, where useful, a short training session on making content edits.

Yes, as a separate paid arrangement agreed after launch. We do not include an open-ended free retainer as standard.

Yes. We can provide a CMS that gives your team full control over the site content after launch. There is no default CMS: we select the CMS, the editing workflow, and permissions for each project.