Good questions
make better work.
Practical answers about how we scope, design, build, and support products.
01 How do you price projects?
We scope around outcomes, uncertainty, team needs, and deliverables. Focused discovery can establish a clearer investment range before a larger build. We share assumptions and exclusions in writing.
02 How long does a project take?
A focused discovery sprint often takes one to three weeks. Product design partnerships and software builds vary with integrations, approvals, and rollout needs; we plan in visible increments rather than promise a universal timeline.
03 What happens during discovery?
We review the current workflow, speak with relevant users and stakeholders, identify constraints and exceptions, and test possible directions. You leave with findings and recommended next decisions.
04 How do you handle accessibility?
Accessibility is part of requirements, interface patterns, content, and testing. We consider keyboard access, screen readers, contrast, focus behavior, and task clarity throughout the work. We do not claim a certification.
05 Can you work with our internal IT team?
Yes. We work alongside internal IT, security, data, and product teams to understand architecture, integration needs, ownership, and release constraints.
06 Who owns the software and design work?
Ownership, licensing, third-party components, and handoff terms are agreed in the project contract. Once applicable project fees are paid, client-specific deliverables are assigned or licensed as stated in that agreement.
07 Do you offer support after launch?
Yes. We can agree on a support window, stabilization period, or ongoing build-and-improve engagement. Response expectations and covered work are documented in scope.
08 What security expectations should we bring?
Tell us about your organization’s policies, data types, access controls, and review process early. We plan accordingly and do not represent unsupported certifications or standards.
09 Can you create or improve a design system?
Yes. We inventory existing patterns, define reusable components and accessible behavior, document decisions, and help teams adopt the system in real product work.
10 Can you work with legacy platforms?
Yes. We assess the current platform, dependencies, operational risk, and user needs, then prioritize modernization in manageable increments. Replacement is not the automatic answer.
11 How do remote collaborations work?
We use working sessions, clear written decisions, prototypes, and regular check-ins. Workshops can be scheduled around U.S. team time zones and operational schedules.
12 What happens after launch?
We review adoption and agreed measures, gather user feedback, address issues, and prioritize the next improvements with your team. A release is a useful checkpoint, not the end of product work.