Frequently asked questions

Choose a partner whose relevant work, reasoning and delivery responsibilities you can verify. Ask about a comparable problem, what the team actually did and which outcomes were measured. Meet the people responsible for your project. Compare proposals on deliverables, exclusions, client responsibilities, change handling, ownership, recurring costs and support. A lower fee can cover a different project. A useful partner should explain what they need to understand before prescribing a solution.

Choose the route that fits the problem and the responsibility your team can carry. A template or website builder can suit straightforward needs when someone can maintain it. A freelancer can suit a focused scope led by one specialist. A studio becomes useful when brand, content, design and engineering need coordinated decisions. Compare the total effort, capability and support each route requires. More custom and more expensive do not automatically mean more useful.

Start with the simplest option that meets the important need. Existing software often suits established tasks; configuration or integration can close a specific gap. Consider a custom build when a consequential workflow cannot work adequately within available products. Compare setup, migration, subscriptions, training, security, support and future changes across the options. Include who will operate the system and how you could leave it later. Buying software still leaves decisions about the complete user experience.

First identify what is failing. If people struggle with information or tasks but the platform is sound, targeted content or experience improvements can be enough. A redesign changes the experience; a rebuild replaces its technical foundation. Rebuilding needs a reason, such as unsupported technology, persistent reliability constraints or requirements the current system cannot meet. Review mobile use, performance, editing needs, integrations, content and migration risk before deciding. Preserve what already works.

No. Your existing identity may have valuable recognition that should be preserved. First establish whether the problem concerns positioning, messaging, visual identity or the experience itself. Sometimes clearer content and a better website are the right changes; sometimes the brand needs broader work. We connect these decisions so the promise people encounter matches the product or service they use. A website redesign does not automatically require starting the brand again.

Yes. Start with the problem, who it affects and what is difficult today. We can help investigate the uncertainty, compare approaches and define a useful first scope. You do not need a complete feature list or a chosen technology. The appropriate discovery work depends on the decision and its consequences. A clear next step might be research, a prototype, a focused improvement or a production build, rather than a larger project by default.

An MVP should let intended users complete an important real task so you can learn from use. Include the permissions, failure states, data handling and operating support that make that journey dependable. Defer additions that do not test the central assumption. If the uncertainty is whether people understand or want the idea, interviews or a prototype can help before a production build. A prototype tests selected assumptions; launching an MVP creates an opportunity to learn, not proof of market demand.

Hooman is an independent international creative studio that creates brands and digital products. We work on identities, websites, web and mobile applications, and software shaped around a business's operations. Strategy, design and engineering stay connected from defining the problem through building and launch. The scope can be a focused part of that work or a wider engagement, depending on what the organization needs and what will make the project useful.

Yes. We build what we design, keeping decisions about the experience connected to how the product behaves in practice. Design helps clarify the problem, information and interactions; engineering makes those decisions work within real constraints. We aim to remove unnecessary complexity without removing capability people need. We can also deliver design or development separately when another team owns the next stage, with responsibilities and handover agreed before work begins.

Hooman was born in Vancouver and works with clients internationally. We agree on working hours, review points and a practical communication rhythm across the time zones involved. A remote engagement still needs clear responsibilities, access to the people who understand the business and timely decisions. We establish how progress, questions and feedback will be shared so location does not leave important decisions unclear.

We are a stronger fit when the project has meaningful business stakes and benefits from connected strategy, design and implementation. A startup might need to define its first product; an established organization might need to improve an experience or replace fragmented workflows. Our experience spans areas including industrial businesses, technology, healthcare, education, investment, construction and commerce. Relevant experience helps us ask better questions; we still need to understand your particular users, systems and requirements.

Yes. We offer focused branding, design and development engagements, and can work with an existing product or internal team. We first establish the outcome, what should be preserved, who owns each decision and who continues the work. A useful handover matters as much as the immediate deliverable. Improving an existing product does not automatically mean replacing it; the scope should follow the actual problem and the team's capabilities.

We start with the business problem and the people affected by it. Depending on scope, useful evidence can include stakeholder conversations, existing analytics, support requests, user interviews and observation of real tasks. These methods answer different questions: analytics can show where something happens, while conversations and observation help explain why. A few interviews can reveal important problems without establishing market-wide demand. We choose the research needed for the next decision rather than treating every project as the same exercise.

Choose measures that reflect the problem the work is meant to solve. For a website, that could be qualified inquiries or successful bookings; for an internal tool, task time, errors or repeated data entry. Record the starting point and agree how change will be observed. Review real use alongside analytics to understand difficulties. A working launch demonstrates delivery. Business improvement requires observation over time, with the effects of other changes considered too.

We agree the problem, scope, responsibilities and decision points before moving through the work. A project can include discovery, strategy, design, implementation, testing and launch, with the sequence shaped by the engagement. Reviews should make the next decision clear and show what is ready to assess. The proposal defines deliverables, assumptions, client inputs and exclusions so everyone understands the work being commissioned and what would require a change.

We agree a shared place for project information and regular points to review progress. Feedback is most useful when it identifies the problem, context and priority, with a clear person responsible for consolidating the client's direction. Reviews need to distinguish an early idea from something ready for approval. The engagement defines the review process and responsibilities; response times and revision allowances should come from the agreement rather than assumptions.

A useful brief explains the business problem, intended users, current situation, desired outcome and any fixed constraints. Include existing systems, content, brand materials, a budget context and an important deadline if you have one. Identify who can make decisions and provide access or approvals. You do not need to prescribe every feature or technology. If research, content creation, migration, procurement review or training is required, say so early so it can be included in the scope.

We assess a material change and agree its effect on deliverables, fees and timing before doing the additional work. A written scope gives both teams something concrete to compare the request against. Sometimes the useful choice is to replace a lower-priority item rather than increase the project. Clear, consolidated decisions help prevent rework, while a written change process keeps new requirements from becoming unspoken commitments.

The schedule depends on scope, uncertainty and what must be ready before launch. Research, design, implementation, content, integrations, migration and testing all take time, as do client decisions and access to information. We estimate the project against its actual requirements and identify dependencies rather than give one duration for every engagement. If a deadline is fixed, agree the essential launch scope and which work can follow later.

We price the agreed scope rather than use one fee for every project. Research, original content, design breadth, custom functionality, integrations, migration and verification all affect the work involved. A useful proposal makes deliverables, exclusions, client responsibilities, payment terms and change handling clear. Compare recurring service and support costs as well as the initial fee. Share your budget context early so we can assess a realistic approach before either team commits to the project.

Yes, particularly when URLs, content or site structure change. Inventory important pages, preserve useful content and map changed URLs to the closest relevant destinations. Plan content transfer, redirects, internal links, indexing settings, sitemaps and post-launch monitoring as part of the migration scope. Careful preparation reduces avoidable mistakes, but rankings can fluctuate while search engines process changes. A visual refresh and a platform migration carry different risks, so establish what is actually changing.

For content-led websites, we can provide an editing interface shaped around the content your team manages. Structured fields, permissions and draft preview can help editors make routine updates without changing the underlying system. New functionality and major layout or structural changes can still require design or development. Agree which changes staff need to make, who can publish and what training or documentation is included before handover.

Plan for domains, hosting, CMS subscriptions and any paid services the product uses, as well as maintenance and future development. Usage, vendor plans and service requirements affect those costs. The architecture should make clear how content is served, which features depend on live services and what happens when a dependency is unavailable. A specific uptime or response-time commitment needs an explicit agreement. Hosting fees alone do not describe the full cost of operating a product.

Under our standard agreement, custom deliverables created for your project are assigned to you on full payment. Hosting, CMS and third-party accounts are established in your name, with Hooman given collaborator access. Pre-existing tools and intellectual property stay with their owners; Hooman's pre-existing IP used in the deliverables is licensed for that use. Account control, copyright ownership and third-party licenses are separate matters. Your signed agreement and scope define the actual terms and materials delivered.

Handover should give the receiving team the access, materials and knowledge needed to operate the agreed product. Depending on scope, that can include source and design files, service accounts, deployment and configuration guidance, recovery responsibilities, documentation and training. Record recurring fees, known limitations, open items and support contacts. Test ordinary operating tasks, such as publishing content or identifying who handles an incident, rather than treating a folder of files as a complete handover.

Our standard proposal includes one year of bug and stability fixes after launch at no additional cost, with priority support. It does not specify a fixed response time. New features, ongoing maintenance, hosting and third-party charges are separate from that coverage. Establish who handles incidents, updates and future changes before launch. Your signed proposal and agreement define the warranty and support terms for your project; the standard template is not a universal guarantee for every engagement.

We can assess how your existing tools and data can work together before choosing a technical approach. Feasibility depends on available APIs, permissions, data quality, vendor limits and who maintains each connection. Our work includes technologies such as React, TypeScript and Sanity, but a product's requirements should drive the choice. Identify how data moves, what happens when a connection fails and who owns ongoing operation before committing to an integration.

AI is useful when a task benefits from interpreting language, finding patterns or producing drafts, and the result can be checked. Start with the task, the cost of an error and who reviews the outcome. A dependable integration also needs appropriate data permissions, realistic evaluation and a way to handle failures. Distinguish suggesting an action from being authorized to take it. If a simpler workflow solves the problem reliably, use that instead, and measure the whole workflow rather than a demo alone.

Agree the accessibility target and testing scope early, then consider content, contrast, keyboard navigation, forms and assistive technology throughout delivery. Automated tools help find issues, but human evaluation is also needed. Requirements can affect design, implementation, content and the schedule, so they belong in the brief. Any formal conformance claim needs evidence for the defined product and scope. A tool score or a vendor's claim does not establish that the finished experience is accessible.

We need those requirements early because they can affect architecture, data handling, vendors, documentation and timing. We can assess the requested work and identify who is responsible for implementation, evaluation and approval. Share technical questionnaires, data-residency rules, access requirements and required service levels before the scope is finalized. A vendor's certification does not certify Hooman or the finished product. Specific legal obligations, audits and operating commitments need explicit agreement and evidence.

Tell us what you are trying to achieve, what exists today and where you need help. Share a useful brief if you have one, or start with the problem and any important constraints. Budget context, timing, systems and the people involved help us assess fit and the next useful step. We can then determine whether a focused engagement, a broader project or further discovery is appropriate before defining a proposal.