# Utilities Studio Full Context Utilities Studio brings product design, web and mobile development, cybersecurity, and video marketing together. Explore our services and the experience behind them. ## Site - Canonical URL: https://utilities.studio/ - Language: en-US - Contact: hello@utilities.studio - Repository: https://github.com/utilities-studio/utilities.studio - Keywords: product studio, cybersecurity services, AI-assisted software development, AI-native product development, product strategy, UX/UI design, full-stack development, React Native development, SaaS product development, video marketing agency, production software delivery, startup product team ## Capabilities - Research & strategy: Product discovery, UX audit, Technical workshop - Design & branding: Website design, Website redesign, Web app design, Mobile app design, Branding and identity, Design prototype, Product redesign - Web & software development: Web development, Website development, AI development, Custom software development, Rapid MVP development, Custom MVP development, No-code app development, Blockchain development, Front-end development, Back-end development, Database design and management, API creation and integration, Cloud deployment and hosting, UI/UX prototyping and wireframing, Website maintenance and optimization, Version control management, Security implementation, CMS customization - Mobile app development: Mobile app development, iOS Apps, Android Apps - Cybersecurity: AI and LLM penetration testing, Penetration Testing, Vulnerability Management, Cloud Security Services, Identity and Access Management (IAM), Threat Intelligence - Video marketing: Product explainers, Product demo videos, AI video production, Video strategy, Video editing and motion - Team extension: Team extension, Dedicated team ## Services ### Product discovery URL: https://utilities.studio/services/research-strategy/product-discovery Product discovery is the work of deciding which problem a product should solve and what a useful first version needs. At Utilities Studio, we examine the brief alongside customer evidence, business goals, and technical constraints. We map the journeys that matter, challenge requirements that lack a clear purpose, and record the decisions. You leave with a practical starting point for design and development, including the questions that still need an answer. Scope: Review the product idea, business goals, and existing customer evidence Map user roles, core journeys, and the problem each journey solves Prioritize a first release against effort, dependencies, and expected value Identify assumptions that need interviews, prototypes, or technical investigation Deliverables: A product brief with the agreed problem and intended users User journeys and a prioritized feature map A first-release scope with acceptance criteria A decision log and a list of unresolved risks Preparation: Bring your current brief, business goals, customer feedback, any analytics, and a list of people who can answer product or technical questions. #### Do I need a finished idea before product discovery? You need a problem worth examining. A rough brief, customer conversations, or an existing workflow can be enough to begin. Discovery helps turn those inputs into decisions; it does not require a complete feature list. #### Does discovery include speaking to our customers? Customer interviews can be part of the scope when access and consent are available. We agree who needs to participate and what we need to learn. If we only have internal input, we make that limitation clear in the findings. #### Can another development team use the discovery work? Yes. The brief, journey maps, priorities, and acceptance criteria give a development team a shared starting point. Technical estimates still depend on that team reviewing the scope, architecture, and any integration requirements. Cost factors: The depth of research, number of user groups, stakeholder involvement, and technical unknowns determine the scope. Recruiting participants and testing prototypes add separate work. Timeline: We plan discovery around the decisions you need to make. Customer access, stakeholder availability, and unresolved technical questions affect the schedule. ### UX audit URL: https://utilities.studio/services/research-strategy/ux-audit A UX audit examines how easily people can complete important tasks in an existing website or product. We review the interface and its content, then compare what we see with analytics, support questions, and research you can share. The work looks at the whole journey, including empty states, errors, and mobile use. The result is a prioritized set of improvements with evidence and an explanation of what each change should help people do. Scope: Walk through priority journeys such as signup, checkout, or task completion Review navigation, interface language, forms, and feedback states Examine mobile layouts and accessibility issues within the agreed audit scope Compare interface findings with available analytics and customer feedback Deliverables: An annotated audit of the agreed pages and product flows A ranked list of usability issues with supporting evidence Suggested improvements and examples for the highest-priority problems A measurement plan for evaluating changes after release Preparation: Share access to a safe test environment, your main user journeys, funnel reports, support themes, and any previous research or accessibility reviews. #### Can you audit a product without analytics? Yes. We can inspect usability, accessibility, and consistency without analytics. We distinguish those observations from measured behavior. Analytics and support evidence help us establish which problems affect the most people. #### Will a UX audit tell us why conversion dropped? An audit can identify plausible obstacles and testable explanations. To understand a drop, we also need the relevant funnel data, time period, traffic changes, and product changes. The findings should guide investigation rather than assign a cause without evidence. #### Does the audit include redesigning the interface? The audit includes recommendations and the examples agreed in scope. A full redesign and implementation are separate work. You can use the findings with your own team or ask us to turn the priorities into a design brief. Cost factors: The number of journeys, user roles, platforms, and research inputs drives the effort. Usability sessions and deeper accessibility testing change the scope. Timeline: The schedule depends on product access, the breadth of journeys, and whether the review includes user sessions. We agree the audit boundary before starting. ### Technical workshop URL: https://utilities.studio/services/research-strategy/technical-workshop A technical workshop gives product and engineering teams a structured way to make decisions before committing to a build. We examine the proposed features, existing systems, data flows, and operational constraints together. Then we compare workable approaches and record their tradeoffs. The goal is an architecture that fits the problem, with clear integration boundaries and a plan for investigating anything the workshop alone cannot prove. Existing products can use the same process to plan a migration or major change. Scope: Review requirements against the existing codebase and infrastructure Map services, data ownership, integrations, and access boundaries Compare architecture options against maintenance and operating constraints Identify technical spikes needed before reliable implementation estimates Deliverables: An architecture outline with service and data-flow diagrams A record of technical choices and their tradeoffs An integration and dependency inventory A delivery outline with risks and investigation tasks Preparation: Bring architecture diagrams, repository access where appropriate, integration documentation, known technical problems, and your release requirements. #### Who should join a technical workshop? The people who understand the business requirements and the engineers responsible for the system should join. For an integration-heavy project, someone who understands the external systems is useful too. We keep the participant list tied to the decisions on the agenda. #### Can you review the stack we already use? Yes. We start with the existing stack, team knowledge, and operational requirements. A recommendation to change technology needs a concrete reason, such as an unsupported dependency or a requirement the current approach cannot meet. #### Will we get a fixed development estimate afterward? The workshop clarifies scope and exposes unknowns. If important assumptions still need a prototype, code review, or vendor confirmation, the estimate must reflect them. We record those dependencies so you can see what prevents a firm commitment. Cost factors: Preparation depth, codebase size, integration complexity, and the number of decisions affect the cost. Hands-on technical investigations require additional scope. Timeline: Preparation and access reviews come before the working sessions. Follow-up investigation depends on what the architecture review uncovers. ### Website design URL: https://utilities.studio/services/design-branding/website-design Website design shapes how a visitor understands your business and decides what to do next. We work on the page structure, content hierarchy, visual direction, and interactions together, so the design has something useful to say. Each important page gets a clear purpose, supported by relevant proof and a sensible next step. Responsive layouts cover the same journey on smaller screens, with attention to readable type, navigation, and accessible controls. Scope: Plan the sitemap and the purpose of each page Develop page structure, content hierarchy, and conversion paths Design responsive layouts using the agreed brand direction Specify interactive states and intentional motion Deliverables: A sitemap and page-by-page content outline Responsive designs for the agreed page templates A reusable library of website components and styles A developer handoff with interaction and layout notes Preparation: Share your current brand files, audience and offer, priority pages, real customer proof, and the action you want visitors to take. #### Do you write the website copy as well as design it? Content work can be included in the brief. We use your offer, audience questions, and verifiable proof to write the pages. Your team reviews factual claims and any wording about pricing, commitments, or regulated services before publication. #### Will the design include mobile pages? Yes. The agreed page templates include responsive layouts. We design how navigation, content, forms, and calls to action adapt to smaller screens, rather than leaving those decisions until development. #### Is development included in website design? Design and development are separate scopes that can form one project. If your team will build the site, the handoff documents components and interactions. If we build it, we can check the implemented pages against the approved design. Cost factors: Unique page templates, content work, illustration, interaction complexity, and the state of your brand assets determine the design scope. Timeline: The schedule depends on page count, content readiness, and design review rounds. We agree the structure and visual direction before extending them across every page. ### Website redesign URL: https://utilities.studio/services/design-branding/website-redesign A website redesign revisits an existing site when the offer, audience, or customer journey has changed. We begin with an inventory of pages, content, and available performance data. That tells us what deserves to stay and where visitors need something better. The work covers structure and copy as well as visual design. When URLs or the publishing system change, the handoff includes migration requirements so the build team can account for existing content and search traffic. Scope: Audit existing pages, navigation, content, and conversion journeys Identify pages to retain, improve, combine, or retire Rework responsive layouts and the visual system Plan URL changes, content migration, and release checks Deliverables: A current-site inventory and redesign priorities A revised sitemap and page content structure Approved responsive page designs and component specifications A migration brief with URL mapping requirements Preparation: Share access to the current site, CMS details, important URLs, search and conversion reports, brand assets, and the reasons you want a redesign. #### Can you redesign the site without changing our CMS? Often, yes. We first check the CMS, theme, and template constraints. If the system can support the intended design and editing workflow, keeping it may reduce migration work. We document any limitations before design approval. #### How do you account for our existing search traffic? We review important landing pages and available search data before changing the structure. The migration plan records retained URLs, redirect requirements, metadata, and internal links. Search performance can still fluctuate after a release, so it needs monitoring. #### Do all pages need to change at once? A phased redesign can work when shared navigation and components remain coherent. We can prioritize a core set of templates, then plan the remaining pages. The approach depends on your CMS and how the current site shares its layout. Cost factors: The page inventory, amount of content rewriting, CMS constraints, custom graphics, and migration requirements determine the effort. Timeline: Content review and page mapping precede the design rollout. A CMS change or substantial URL migration adds preparation and release validation. ### Web app design URL: https://utilities.studio/services/design-branding/web-app-design Web app design organizes the screens and interactions of software people use in a browser. The work starts with tasks: what users need to do, what information they need, and what their role allows them to change. We map those flows before refining the interface. Tables, forms, permissions, and error states get the same attention as the main dashboard. A reusable component system keeps the experience consistent as the product grows. Scope: Map user roles, permissions, and primary task flows Design navigation, dashboards, forms, and data-heavy views Define loading, empty, error, and success states Create responsive component patterns for the product Deliverables: Role-based journey maps and wireframes High-fidelity interface designs for the agreed workflows A component library with states and usage notes A clickable prototype and implementation annotations Preparation: Bring product requirements, user roles, representative data, existing components, and access to the current application if one exists. #### Can you design a dashboard with complex permissions? Yes. We need to understand which roles can view, create, edit, and approve each type of information. We map those permissions into the interface and document the behavior for developers. The backend must enforce the same rules. #### Do you include the states outside the main user flow? The design scope should include empty data, loading, validation, permission restrictions, and recoverable errors. These states explain how the product behaves when conditions differ from the ideal path, so they belong in the handoff. #### Can the design use our existing component library? Yes. We review the library and design within its supported patterns where they meet the need. Any new components or variations are documented, so your team can assess their implementation and maintenance cost. Cost factors: User roles, workflow complexity, data density, responsive requirements, and the condition of an existing design system determine the scope. Timeline: The schedule follows the agreed workflows. Complex permissions and incomplete product requirements need resolution before screen design can progress reliably. ### Mobile app design URL: https://utilities.studio/services/design-branding/mobile-app-design Mobile app design turns product requirements into interfaces people can use on a phone. We consider small screens, touch input, interruptions, and the conventions of the intended platform. The work includes navigation and everyday tasks, plus practical moments such as asking for a permission or recovering from a lost connection. We document the behavior between screens so the development team can implement a coherent experience, including the states a static mockup cannot show. Scope: Map mobile journeys, onboarding, and navigation Design platform-appropriate controls and touch interactions Define permissions, notifications, and connectivity states where relevant Adapt layouts for the agreed devices and accessibility needs Deliverables: Mobile flow maps and wireframes iOS and Android designs within the agreed platform scope An interactive prototype for the main journeys Component specifications and behavior notes for development Preparation: Share your product goals, target devices, platform choice if decided, existing brand or app designs, and any required device integrations. #### Do iOS and Android need different designs? They can share a visual identity and many components. Navigation, permissions, system controls, and some interaction patterns still need platform-specific decisions. We agree where the experience should differ and where a shared approach makes sense. #### Can you design an app before its backend exists? Yes, if we can agree the data and behavior each flow needs. We record those assumptions in the design handoff. A technical review helps catch features that depend on unavailable data, device capabilities, or integration support. #### Will the prototype work like the finished app? A prototype can demonstrate selected journeys, transitions, and interactions. It usually does not contain production data, real payments, or working authentication. We define which decisions the prototype needs to support before building it. Cost factors: The number of platforms, workflows, device sizes, custom interactions, and platform-specific screens determines the design effort. Timeline: We establish the mobile navigation and core journeys first. Platform differences, product decisions, and prototype feedback influence the remaining schedule. ### Branding and identity URL: https://utilities.studio/services/design-branding/branding-and-identity Branding and identity work defines how a business presents itself and how its team applies that identity. We start with the offer, audience, and the reasons a customer would choose you. Those decisions inform the language and visual direction. The work can include a logo, typography, colors, and examples of the identity in use. The result should be a practical system your team can use across the website, product, and marketing materials. Scope: Clarify the audience, positioning, and brand attributes Develop and refine an agreed visual identity direction Define typography, color, logo usage, and imagery principles Apply the identity to representative customer touchpoints Deliverables: A positioning and messaging brief Logo files and the agreed visual identity assets Brand guidelines with practical usage examples Templates for the materials included in the brief Preparation: Bring existing brand files, customer insight, your business story, competitors you want to distinguish yourself from, and the materials your team uses most. #### Can we keep our existing logo? Yes. An identity project can retain a recognizable logo and improve the typography, colors, imagery, and application around it. We review what customers already recognize and what the business needs before proposing a change. #### Is naming included in branding and identity? Naming is a distinct piece of work and needs to be specified in the brief. If included, the scope must cover the naming criteria and review process. Legal clearance and trademark advice require an appropriate specialist. #### What makes the brand guidelines useful to our team? The guidelines should answer everyday questions: which logo file to use, how type and color work, and how to lay out common materials. We include examples tied to the touchpoints your team actually creates. Cost factors: Strategy depth, whether the logo changes, the number of concepts, and the range of applications and templates determine the scope. Asset licenses may add separate costs. Timeline: Positioning decisions come before the visual system. Stakeholder review, identity approval, and the number of applications affect the schedule. ### Design prototype URL: https://utilities.studio/services/design-branding/design-prototype A design prototype is an interactive model of a product or feature. It lets people try selected journeys before the team commits to production development. We define what the prototype needs to answer, choose the right level of detail, and build the screens and interactions around that question. The work is useful for testing comprehension, reviewing a proposed workflow, or explaining an idea to stakeholders. Findings should inform the next version of the product brief. Scope: Define the questions and journeys the prototype must cover Create wireframes or polished screens at the appropriate fidelity Connect interactions into a usable demonstration Review feedback and document changes to the proposed flow Deliverables: A prototype brief with its purpose and boundaries A shareable interactive prototype Task scenarios and a feedback guide A findings summary and recommended next design decisions Preparation: Share the idea, the decision you need to make, any sketches, representative content, and the people who will review or test the prototype. #### Should the prototype look finished? That depends on the question. Simple wireframes can expose workflow problems before visual details distract reviewers. A polished prototype is more useful when testing content, visual hierarchy, or a presentation that needs to show the intended experience. #### Can we use the prototype to test with customers? Yes, within the journeys it supports. We define realistic tasks and explain where behavior is simulated. Recruitment, moderated sessions, and research analysis can be included when that work is part of the agreed scope. #### Can developers turn the prototype directly into the app? The prototype communicates design intent. It does not replace production architecture, backend logic, or engineering. Developers use its flows and component specifications as inputs, and review the technical feasibility before implementation. Cost factors: Prototype fidelity, the number of branches and states, animation detail, and whether user testing is included affect the effort. Timeline: A focused question keeps the prototype bounded. The schedule depends on the journeys, design detail, and access to reviewers or test participants. ### Product redesign URL: https://utilities.studio/services/design-branding/product-redesign Product redesign improves an existing application when its interface or workflows no longer fit the way people use it. We review the product, customer evidence, and technical constraints before changing the screens. The work can address confusing navigation, an expanded feature set, or inconsistent patterns across teams. Existing users matter throughout: we account for familiar behavior, data, and migration needs while documenting how the revised experience should work. Scope: Review current journeys, support themes, and product usage evidence Restructure navigation and workflows around user tasks Redesign priority screens and shared interface patterns Plan staged adoption, migration states, and implementation priorities Deliverables: A redesign brief tied to observed product problems Current and proposed journey maps Revised screens and a reusable component system A rollout design plan with developer specifications Preparation: Share product access, user feedback, analytics, current designs, known technical constraints, and a list of workflows customers depend on. #### How do you avoid disrupting existing users? We identify familiar workflows and the reasons people rely on them before changing the interface. The design can include migration guidance, staged changes, and familiar patterns. Testing with current users helps reveal where the new flow needs explanation. #### Can we redesign one area of the product first? Yes. A contained workflow can be a useful starting point if it has clear boundaries. We also inspect shared navigation and components so the change does not create a conflicting experience elsewhere in the product. #### Do we need to rebuild the application? A redesign does not automatically require a rebuild. Your engineering team reviews the proposed changes against the current architecture and component system. That review determines which improvements fit the existing application and which need deeper technical work. Cost factors: Product size, role complexity, existing research, design-system condition, and the need to support old and new workflows determine the scope. Timeline: The work follows prioritized journeys and product decisions. A staged release may need extra design states and coordination with the engineering roadmap. ### Web development URL: https://utilities.studio/services/fullstack-development/web-development Web development turns product requirements into a working application people access through a browser. We build the interface alongside the backend, data model, and integrations it depends on. That includes permissions and the less visible behavior, such as validation, retries, and useful errors. The project scope also accounts for testing and deployment. Our founders bring experience building scheduling systems, subscription products, and applications that connect several business tools. Scope: Define application architecture, data models, and API contracts Build responsive interfaces and backend business logic Integrate authentication, payments, and external systems as scoped Test core workflows and prepare deployment and monitoring Deliverables: Application source code in the agreed repository Documented data models and integration contracts Automated checks for the agreed critical workflows Deployment configuration and operational handoff notes Preparation: Bring requirements or designs, user roles, existing repositories if relevant, integration documentation, and your deployment or hosting constraints. #### What is the difference between web and website development? Web application development focuses on software behavior, such as managing accounts, running workflows, or working with data. Website development usually focuses on publishing content and helping visitors understand an offer. Some projects need both, and we separate the requirements during scoping. #### Can you take over an existing web application? Yes, after reviewing the repository, dependencies, architecture, and deployment process. That review helps us understand the system and identify risks before estimating new features or changes. Access to current maintainers and documentation helps the transition. #### How do you decide which technology to use? We consider the application requirements, existing systems, team experience, hosting constraints, and long-term maintenance. The chosen stack should have a clear reason for fitting your project. We document the decisions before the build expands. Cost factors: Workflow complexity, integrations, permissions, migration, and reliability requirements determine the build effort. Existing code may need review before an estimate is credible. Timeline: We agree milestones around working product flows. Integration access, technical unknowns, and acceptance feedback affect the delivery schedule. ### Website development URL: https://utilities.studio/services/fullstack-development/website-development Website development turns a design and content plan into a working site. We build responsive page templates, connect the agreed publishing tools, and implement forms and other visitor actions. Search essentials, accessible markup, and performance are part of the build requirements. We also consider how your team will update the site after release. The project ends with tested pages, deployment setup, and the documentation needed to manage the agreed editing workflow. Scope: Build responsive page templates and reusable components Configure content editing and migrate agreed material Implement forms, analytics events, and required integrations Check performance, accessibility, metadata, and release behavior Deliverables: A working website with the agreed pages and content A configured publishing workflow and editing notes Tested forms, links, and integration flows Deployment files and a documented release checklist Preparation: Share approved designs and content, current hosting and CMS details, form destinations, analytics requirements, and any URLs that need redirects. #### Will our team be able to edit the site? We define the editing workflow during scoping. Your team may need to update service pages, publish articles, or manage case studies. Those needs inform the CMS choice, content fields, permissions, and the editing guidance delivered with the site. #### Does website development include SEO? The build can include technical foundations such as metadata, canonical URLs, sitemaps, structured data where appropriate, and crawlable internal links. Search strategy and ongoing content production are separate scopes. Technical setup alone does not guarantee search rankings. #### Can you connect our contact form to our CRM? Yes, when the CRM supports an appropriate integration. We need its documentation and access to a test account or environment. The form flow should include validation, delivery confirmation, failure handling, and the agreed treatment of personal data. Cost factors: Page templates, CMS requirements, migration volume, motion detail, integrations, and content readiness drive the development scope. Timeline: Development depends on approved designs and usable content. CMS migration, account access, and integration review can affect the release date. ### AI development URL: https://utilities.studio/services/fullstack-development/ai-development AI development adds model-based capabilities to a product or internal workflow. We begin with a task that can be described and evaluated, then examine the data, integrations, and human decisions around it. The implementation may involve retrieval, generated content, or an agent that uses approved tools. We treat evaluation, access controls, and failure handling as part of the product. Our founders have built AI coaching experiences and automation for product and engineering teams. Scope: Define the task, success criteria, and representative evaluation examples Design data retrieval, model integration, and permitted tool access Build the AI workflow and its product interface Implement evaluation checks, monitoring, and fallback behavior Deliverables: A scoped AI workflow with documented data boundaries A working integration and the agreed product experience An evaluation set with acceptance criteria and recorded results Operational notes covering model configuration, limits, and review needs Preparation: Bring examples of the task, representative data you may use, acceptable and unacceptable outputs, system integrations, and privacy or review requirements. #### Do we need to train our own AI model? That depends on the task and the evidence from evaluation. An existing model with suitable context or retrieval may be enough. We compare options against output quality, privacy, latency, and operating cost before committing to a more complex approach. #### How do you check whether the AI is reliable? We agree representative examples and failure cases for the actual task. Evaluation checks the outputs against those expectations, including when the system should decline or ask for help. A model change or workflow change should trigger relevant evaluation again. #### Can the AI take actions in our other systems? It can when the integration and permissions support that scope. We define the allowed actions, the identity used to perform them, and where a person must approve a consequential step. Tool access needs testing as well as the generated response. Cost factors: Data preparation, retrieval complexity, tool integrations, evaluation depth, and privacy requirements affect development. Model and infrastructure usage add operating costs. Timeline: We begin with a representative task and evaluation before expanding the feature. Data access, quality issues, and integration permissions influence the schedule. ### Custom software development URL: https://utilities.studio/services/fullstack-development/custom-software-development Custom software development creates an application around requirements that existing tools do not adequately cover. We examine the workflow and the people who use it before deciding what needs custom code. The work includes business rules, data models, integrations, and the interface that brings them together. It also needs a clear plan for permissions and maintenance. Our founders have built scheduling infrastructure, payment systems, and platforms that consolidate several operational tools into one application. Scope: Map business workflows, rules, exceptions, and user roles Design the data model and system architecture Implement the application and agreed external integrations Test business-critical paths and prepare the operational handoff Deliverables: A requirements baseline with business rules and acceptance criteria Working software and source code Integration documentation and agreed data migration tooling Test evidence, deployment configuration, and maintenance guidance Preparation: Share the current workflow, recurring problems, example data, existing software and contracts, and the people who understand the exceptions. #### How do we know whether we need custom software? Start with the specific gaps in your current tools: a missing workflow, repeated manual work, integration limits, or control over data. We examine whether configuration or a smaller integration could solve the problem before scoping a full custom application. #### Can you connect software we already depend on? We review each system for supported APIs, webhooks, export formats, and access limits. Those details determine what a reliable connection can do. Where a vendor imposes constraints, we record them in the design and delivery plan. #### Who owns and maintains the code after delivery? Ownership, access, and ongoing support should be explicit in the project agreement. We plan repository access and technical documentation for the agreed handoff. Maintenance can sit with your team or be defined as a separate ongoing scope. Cost factors: Business-rule complexity, integrations, data migration, user permissions, and operational requirements determine the effort. Legacy systems often need discovery before estimating. Timeline: We plan milestones around working business workflows. Vendor access, data cleanup, and review of complex rules affect the delivery schedule. ### Rapid MVP development URL: https://utilities.studio/services/fullstack-development/rapid-mvp-development Rapid MVP development creates a deliberately narrow first product so you can learn from actual use. We define the primary journey and the assumptions the release should test, then choose an implementation that suits that boundary. Existing services and familiar components can reduce custom work. Essential permissions, data handling, and release checks still belong in the plan. The result is a working first version with a clear account of what it covers and what comes later. Scope: Choose the primary user journey and first-release learning goals Reduce scope and identify suitable existing services or components Build a working flow with the essential supporting functionality Test the release and set up the agreed feedback or usage signals Deliverables: A bounded MVP brief and deferred-feature list A working first release with the agreed core journey Source code and deployment setup A feedback plan and a prioritized follow-up backlog Preparation: Bring the problem, intended first users, the assumption you need to test, essential features, and any real deadline or budget constraint. #### What makes an MVP project rapid? A narrow scope and quick decisions make the biggest difference. We focus on one useful journey, reuse suitable services, and defer features that do not help answer the first product question. The technical approach still needs to support safe handling of real users and data. #### Can an MVP accept payments or real customer data? Yes, when those capabilities are part of the agreed scope and receive the necessary implementation and testing. Calling something an MVP does not remove the need for access controls, payment error handling, or clear data ownership. #### What happens if the initial feedback changes the idea? We use the feedback to revise the priorities before extending the product. The first release should be small enough that changing direction is manageable. New requirements need a fresh scope review instead of quietly expanding the original commitment. Cost factors: The core journey, required integrations, authentication, payments, and release requirements drive effort. A broader feature list reduces the benefit of a rapid approach. Timeline: The schedule depends on how tightly the first release is defined and how quickly product decisions are made. We estimate after the core journey is agreed. ### Custom MVP development URL: https://utilities.studio/services/fullstack-development/custom-mvp-development Custom MVP development builds the essential version of a product whose core behavior needs a tailored implementation. The scope stays focused, but the data model, workflow, and integrations reflect the actual product requirements. We work through architecture and design before implementing a complete user journey. Release checks and operating basics are included in the plan. You get a first version that can test the idea, with documented technical decisions and a practical backlog for what follows. Scope: Define the first product release and its technical requirements Design the custom workflow, architecture, and data model Build the interface, backend, and agreed integrations Validate the product journey and prepare deployment and handoff Deliverables: An MVP specification with acceptance criteria A working custom product and source repository Technical documentation and deployment configuration A release report and a prioritized next-stage backlog Preparation: Share the product brief, prototype if available, initial user roles, required integrations, and the evidence that defines a useful first release. #### How is a custom MVP different from a rapid MVP? Both limit the first release to essential functionality. A custom MVP spends more of the effort on product-specific architecture and behavior. A rapid approach favors an especially narrow scope and existing services where they fit. The right choice depends on what makes your product useful. #### Can we start from an existing prototype? Yes. We review the prototype as a product input and identify which flows it demonstrates. Production development still needs decisions about data, permissions, integrations, and failure behavior that may not appear in the prototype. #### Will the MVP be the foundation for later releases? We design it with the known roadmap in mind and document the limits of the first version. Future requirements may still call for changes. A clear data model, manageable components, and tested core workflows make those later decisions easier. Cost factors: Custom business logic, architecture, role permissions, integrations, and data requirements determine the build scope. Prototype quality affects how much design work remains. Timeline: Timing follows discovery, product design, implementation, and release review. Complex integrations or unclear acceptance criteria need resolution before a reliable schedule. ### No-code app development URL: https://utilities.studio/services/fullstack-development/no-code-app-development No-code app development uses a visual platform to create application screens, data structures, and workflows. It can be a practical choice when the required behavior fits the platform and your team needs to manage it directly. We assess those limits before building, including permissions, integrations, export options, and recurring charges. The work then turns the agreed workflow into a usable application, with testing and documentation for the people who will maintain it. Scope: Assess the workflow against candidate platform capabilities and limits Configure data structures, screens, permissions, and business rules Connect supported integrations and automate agreed actions Test workflows and document the editing and administration process Deliverables: A platform fit assessment with limitations and operating costs to confirm A configured application in the agreed platform A record of integrations, permissions, and workflow rules Administration instructions and test results Preparation: Share the workflow, example data, required integrations, expected user roles, and any existing platform account or preference. #### How do you decide whether no-code is suitable? We check the actual requirements against the platform: data structure, permissions, expected use, integrations, and customization. A small prototype can test uncertain behavior. If an essential requirement does not fit, we discuss a custom or mixed implementation. #### Can we move away from the platform later? That depends on its export options and how much application logic lives inside it. We review data portability and any available code export before selection. Migration can require rebuilding workflows even when the data itself is easy to export. #### Is no-code always cheaper than custom development? No. It can reduce initial development work for a suitable workflow, but subscriptions, usage charges, workarounds, and future migration can change the total cost. We make those factors visible when comparing approaches. Cost factors: Workflow complexity, integrations, permissions, custom extensions, and platform constraints affect build effort. Platform subscriptions and usage charges are separate operating costs. Timeline: Platform evaluation comes first. The build schedule depends on the workflows, integrations, and any features that need workarounds or custom extensions. ### Blockchain development URL: https://utilities.studio/services/fullstack-development/blockchain-development Blockchain development creates application behavior that uses a blockchain alongside the interface and services around it. We start by deciding which records or actions need to be on-chain and why. That choice affects wallet interactions, contract design, data availability, and operating costs. The application also needs understandable transaction states and recovery paths. We define those boundaries before implementation and include explicit review requirements for any contract behavior that handles valuable assets. Scope: Define the use case and the boundary between on-chain and off-chain logic Design contract interactions, permissions, and data flows Build the application interface, wallet flow, and supporting services Test transaction behavior and document deployment and review requirements Deliverables: A technical brief with the selected network and architecture rationale Application code and contract code within the agreed scope Test coverage for the agreed transaction and failure paths Deployment instructions and an explicit external-review checklist Preparation: Bring the use case, reasons for using a blockchain, intended network if decided, asset and permission requirements, and required external review arrangements. #### Does our product need a blockchain? The answer depends on the requirement. We look for a concrete need for shared state, independently verifiable records, or on-chain assets. If a conventional application meets the requirement more simply, that should be part of the technical discussion. #### Is a smart contract security audit included? Development testing and an independent smart contract audit are distinct scopes. Any audit requirement, reviewer, remediation process, and deployment gate must be agreed explicitly. A working application or passing test suite should not be described as an audited contract. #### How do you handle failed or pending transactions in the interface? The interface needs to distinguish wallet approval, transaction submission, confirmation, rejection, and failure. We define those states around the chosen network and provider so users can understand what happened and what they can safely do next. Cost factors: Contract complexity, network choice, wallet integrations, indexing, backend needs, and external security review affect scope. Transaction and infrastructure fees are separate. Timeline: Architecture and contract requirements come before implementation. Independent review, remediation, and deployment approvals can affect the release schedule. ### Mobile app development URL: https://utilities.studio/services/app-development/mobile-app-development Mobile app development turns product designs into working software for iOS or Android. The build includes the screens and device behavior, plus the APIs, authentication, and services the app needs. We account for interrupted sessions, connectivity changes, and platform-specific requirements in the scope. Testing and store submission preparation are part of the release plan. Our founders have delivered mobile product work, including the web and mobile rebuild of House of Manifestation. Scope: Choose the mobile architecture and define backend contracts Build the agreed iOS and Android product journeys Integrate authentication, payments, notifications, and device features as scoped Test agreed devices and prepare builds and store submission materials Deliverables: Mobile application source code and platform build configuration Backend integrations and documented API requirements Device test results and release candidates Submission preparation and maintenance handoff notes Preparation: Share designs, platform requirements, backend documentation, required device features, developer-account details, and any current mobile application code. #### Should we build a native or cross-platform app? The choice depends on device features, interaction requirements, performance needs, and the team that will maintain the product. We review those factors before recommending an approach. Sharing code can be useful, but some behavior still requires platform-specific work. #### Can the app use our existing backend? Yes, if the backend supports the mobile requirements. We review authentication, API behavior, data access, and any device-specific needs. Missing capabilities become part of the backend scope rather than an assumption left to the app build. #### Do you handle App Store and Google Play submission? Submission preparation and support can be included in the release scope. Your organization needs the appropriate developer accounts and approved product information. Store review is controlled by Apple and Google, so approval and timing cannot be guaranteed. Cost factors: Platforms, device features, backend readiness, offline behavior, payments, and device coverage determine effort. Store and service accounts can carry separate charges. Timeline: The schedule includes product implementation and testing. Backend dependencies, developer-account setup, and store review affect when the app can reach users. ### Team extension URL: https://utilities.studio/services/team-extension/team-extension Team extension adds a defined role to an existing product organization. Your team keeps its product direction and delivery structure while the added person works within agreed responsibilities. We establish the required expertise, expected contribution, and collaboration process before an engagement begins. Repository access, design context, review standards, and an accountable internal contact matter as much as the role description. The arrangement should make ownership and communication clear to everyone doing the work. Scope: Define the role, required expertise, and expected contribution Agree reporting, review standards, and collaboration practices Onboard into the product context and relevant systems Review progress and hand over work within the agreed engagement Deliverables: A written role scope and responsibility map An onboarding and access checklist Design or engineering outputs defined by the agreed backlog Progress records and handoff documentation Preparation: Share the role gap, product context, stack or design tools, expected responsibilities, working-hour needs, and the internal person who will manage priorities. #### Who manages the work in a team extension engagement? Your product and delivery leads normally manage priorities within the agreed role. We clarify who assigns work, reviews it, and accepts the outcome. If you need a team to own delivery coordination as well, a dedicated-team scope may fit better. #### Can the person work inside our existing process? That is the purpose of the engagement. We review your tools, ceremonies, code or design standards, and communication needs before starting. Any required working-hour overlap and access restrictions should be stated in the agreement. #### How do we handle the end of the engagement? The scope should include a clear handoff: current work, outstanding decisions, documentation, and access removal. The notice period and any transition support are contractual details to agree before the work starts. Cost factors: Role seniority, required expertise, engagement length, expected capacity, and coordination needs determine the commercial scope. Availability is confirmed during scoping. Timeline: Start dates depend on role fit, confirmed availability, contracting, and access preparation. The engagement schedule follows the agreed team responsibilities. ### Dedicated team URL: https://utilities.studio/services/team-extension/dedicated-team A dedicated-team engagement brings together the roles needed to deliver an agreed product roadmap. We define the work, responsibilities, and decision process before deciding the team composition. The arrangement can cover design and engineering, with delivery coordination specified in the agreement. Your business retains a clear route for setting priorities and reviewing outcomes. Capacity, access, and communication expectations are explicit so the team can work with the context it needs. Scope: Review the roadmap and define the required disciplines Agree team responsibilities, capacity, and decision ownership Establish planning, reviews, and release practices Deliver the agreed backlog with documentation and progress visibility Deliverables: A team and responsibility plan tied to the roadmap An agreed delivery and communication process Product increments and reviewable design or code outputs Release records, technical documentation, and transition materials Preparation: Bring the roadmap, current product and team context, budget constraints, delivery responsibilities you want covered, and the people who approve priorities. #### How is a dedicated team different from team extension? Team extension fills a defined role inside your existing delivery structure. A dedicated team groups the roles needed for a body of work and can include delivery coordination. The agreement should state which product and technical decisions remain with your business. #### Can the team composition change as the product changes? It can, subject to an agreed scope and confirmed availability. A product may need more design early and different engineering expertise later. We review those needs against the roadmap instead of assuming the same role mix always fits. #### How will we see what the team is delivering? We agree review points, access to the working backlog, and the format for demonstrations or release reviews. Progress should be visible in working product increments and the decisions behind them. Reporting frequency belongs in the engagement plan. Cost factors: Team composition, capacity, product complexity, coordination responsibility, and engagement duration determine the cost. Staffing and availability require confirmation. Timeline: The start depends on the agreed roles, availability, onboarding, and system access. Delivery milestones follow the prioritized roadmap and known dependencies. ### Product explainers URL: https://utilities.studio/services/video-marketing/product-explainers A product explainer helps a buyer understand what a product does and why it matters to their work. We begin with the audience, the problem, and the next action the video should support. Then we turn that brief into a script, visual treatment, and finished edit. Product screens, animation, narration, and other footage serve the explanation. Founder Soaham Dixit has created explainers for products including VWO, Artwork Flow, GrowthDay, and Truecaller for Business. Scope: Define the audience, central message, and intended next action Write the script and develop the visual treatment Produce the agreed animation, screen sequences, and narration Edit the video and prepare agreed channel versions and captions Deliverables: An approved brief and final script A storyboard or visual treatment A finished explainer in the agreed export formats Caption files and specified cutdowns or aspect ratios Preparation: Share the product, intended audience, placement, brand files, approved claims, and examples of customer questions the video should answer. #### What is the difference between an explainer and a product demo? An explainer establishes the problem and explains the value of the product. A demo shows how a task works inside it. An explainer can use product footage, but its structure should help the audience understand the offer before asking them to follow detailed steps. #### Do we need a script before contacting you? No. We can develop the script from a product conversation, existing messaging, and verified customer evidence. We need access to someone who understands the product and can review the claims before production begins. #### Can the same explainer work on our website and in ads? It may need different openings, lengths, framing, or calls to action for each placement. We plan those versions before production so the footage and animation can support them. The agreed deliverables specify each export and cutdown. Cost factors: Runtime, visual style, animation complexity, narration, asset readiness, and the number of channel versions determine production scope. Timeline: Production follows brief, script, visual treatment, and edit approval. Product access, stakeholder feedback, and the complexity of the visuals affect the schedule. ### Product demo videos URL: https://utilities.studio/services/video-marketing/product-demo-videos A product demo video walks a buyer through a useful task inside your product. We choose a scenario the audience recognizes, prepare the product environment, and build the narrative around what happens on screen. The edit guides attention without hiding the behavior someone needs to evaluate. Narration and annotations explain the decisions that matter. Founder Soaham Dixit has produced guided demos, including a Tontine walkthrough that explains automated price testing through the product itself. Scope: Choose a buyer scenario and map the demonstration steps Prepare safe sample data and the recording environment Capture product screens and create narration or annotations Edit the walkthrough and prepare the agreed sales or marketing versions Deliverables: A demo outline and approved narration script A recording plan with the required product states A finished demo video in the agreed formats Captions and a list of product screens used for future updates Preparation: Provide a demo account, safe sample data, the workflow to demonstrate, target buyer questions, and a product expert who can verify every step. #### How much of the product should a demo show? Enough to complete the buyer scenario. A focused workflow is usually easier to follow than a tour of every feature. If different buyers need different tasks explained, separate demos may be more useful than one long walkthrough. #### Can we record a product that is still changing? Yes, if the demonstrated flow is stable enough to review. We agree which screens and claims need approval and identify likely update points. Significant interface changes after recording can require new captures and edits. #### Can our sales team use the demo in follow-up emails? Yes. We can plan the video around the objection or workflow a salesperson needs to explain. File format, hosting needs, captions, and any shorter versions should be included in the brief so the finished asset suits that use. Cost factors: Demo complexity, product readiness, recording setup, narration, motion annotations, and version count determine the work. Product changes can require recapture. Timeline: The schedule depends on a stable demonstration environment and approval of the workflow. Screen capture begins after the scenario and sample data are ready. ### AI video production URL: https://utilities.studio/services/video-marketing/ai-video-production AI video production uses generative tools as part of making a finished video. The creative work still needs a brief, script, visual direction, and an editor who judges what belongs in the final cut. We plan sequences around the story and choose a generated, live-action, or animated approach where it fits. Founder Soaham Dixit works across AI-led video and hybrid production, including a fully generated Jetseen ad described in his portfolio. Scope: Define the story, intended audience, and visual direction Plan generated scenes and the assets needed for consistency Generate and review shots, voice, or supporting elements as agreed Edit, finish, and export the video for the intended placements Deliverables: An approved creative brief and script A visual treatment and planned shot sequence A finished video with the agreed sound and finishing work Caption files and agreed channel variations Preparation: Share the audience, message, placement, brand references, approved assets and permissions, and any scenes or product details that must remain accurate. #### Will the entire video be generated by AI? Only if that approach fits the brief. A video can combine generated shots with real product footage, live action, or animation. We decide the production approach around what the audience needs to see and what the story can represent accurately. #### How do you keep generated scenes visually consistent? We establish the look and recurring visual references before producing the sequence. Each shot is reviewed against that direction and the surrounding edit. Some scenes need regeneration or another production method when the output does not hold together. #### Can you use a real person or brand asset in generated scenes? We need the appropriate permission for supplied likenesses, voices, and brand assets, and the chosen tools must support the intended use. The brief should identify those assets early so production does not depend on material that cannot be used. Cost factors: Scene complexity, continuity needs, generation iterations, voice production, finishing, and the number of final versions affect scope. Tool usage and licensed assets may add costs. Timeline: The schedule depends on the visual treatment, shot complexity, and revision needs. Generated scenes require review before they can be treated as usable footage. ### Video strategy URL: https://utilities.studio/services/video-marketing/video-strategy Video strategy decides what to make, who it is for, and how the finished work will be used. We review your product message, existing content, buyer questions, and available performance evidence. Then we map the videos that can help at specific points in the customer journey. Each priority gets a clear brief and a way to assess its contribution. The scope can also include a repeatable production workflow for the people making and publishing the content. Scope: Review existing video, product messaging, and available performance data Map buyer questions and intended placements across the customer journey Prioritize video concepts and write actionable production briefs Define measurement and a repeatable production and publishing workflow Deliverables: A video content audit with opportunities and gaps A prioritized video roadmap Production briefs with audience, message, placement, and next action A measurement plan and workflow documentation Preparation: Bring existing videos, channel and campaign reports, customer questions, product messaging, sales feedback, and the people responsible for production and publishing. #### Can you work with videos we have already produced? Yes. We review their message, intended audience, placement, and available performance data. Some assets may need a different edit or distribution plan. Others may leave a buyer question unanswered and need a new brief. #### How do you decide whether a video is working? We connect the measurement to its purpose. A demo may need to support a sales conversation, while an ad may aim for a specific next action. Watch behavior, traffic, conversions, and qualitative feedback should be interpreted in the context of distribution and attribution limits. #### Does strategy include making the videos? The strategy scope produces the priorities, briefs, and measurement plan. Production can follow as a separate scope or be planned as part of a larger engagement. Keeping the deliverables explicit makes it clear which videos will actually be produced. Cost factors: The number of products, audiences, channels, existing assets, and the depth of performance review determine the strategy scope. Team training adds separate work. Timeline: The schedule depends on access to content, marketing and sales input, and performance data. Roadmap approval comes before individual production planning. ### Video editing and motion URL: https://utilities.studio/services/video-marketing/video-editing-and-motion Video editing and motion work turns raw footage, recordings, and graphic assets into a finished piece. We establish the audience and purpose, then build an edit with a clear sequence and appropriate pace. Motion graphics can explain an idea, direct attention, or keep product footage readable. Sound, color, and captions complete the viewing experience. Soaham Dixit brings experience across marketing videos, motion graphics, long-form episodes, and other content produced during his work with GrowthDay. Scope: Review source footage and agree the structure and intended use Edit the story, pacing, dialogue, and supporting visuals Create agreed motion graphics, titles, and product annotations Finish sound and color, then prepare captions and channel exports Deliverables: A finished master edit in the agreed format Motion graphics and titles included in the approved treatment Caption files and specified social or platform versions Project files and asset organization where included in the agreement Preparation: Provide original footage and audio, brand assets, the intended audience and placement, reference videos, and any required messages or delivery formats. #### Can you edit footage recorded by our team? Yes. We review the footage, audio, and supporting assets before confirming scope. The available material sets practical limits on image and sound quality. A clear brief and a reference edit help establish what the finished piece needs to do. #### Can one recording become several shorter videos? It can when the recording contains useful standalone moments. We identify clips that make sense without the full episode and adapt their opening, framing, and captions. The agreed scope specifies the number and purpose of the shorter edits. #### Are editable project files included? Project-file handoff should be agreed before work begins. Some fonts, music, plugins, or stock assets have separate license requirements. We document the tools and assets needed to open and reuse the project when handoff is part of the scope. Cost factors: Source-footage volume, finished runtime, motion complexity, sound cleanup, review rounds, and version count determine the edit scope. Licensed assets may add costs. Timeline: We estimate after reviewing the footage and brief. Missing assets, significant story changes, and complex motion sequences affect the finishing schedule. ### AI and LLM penetration testing URL: https://utilities.studio/services/cyber-security/ai-llm-penetration-testing AI and LLM penetration testing examines how an AI application behaves when someone tries to bypass its intended boundaries. The assessment looks beyond the model response to the data it can retrieve and the actions its tools can take. We define an authorized scope, test realistic abuse scenarios, and document reproducible findings with remediation guidance. Our Head of Cybersecurity, Sheeraz Ali, lists AI and LLM pentesting, prompt injection, agentic tool abuse, and RAG attacks among his areas of expertise. Scope: Map the application, model interactions, retrieval sources, and tool permissions Test prompt injection and instruction-boundary failures in the agreed environment Assess unauthorized data access and misuse of connected tools Document reproducible findings and review remediation priorities Deliverables: An agreed assessment scope and rules of engagement A report with evidence, affected components, and risk context Reproduction steps and practical remediation recommendations A findings review and retest results when retesting is included Preparation: Share an architecture overview, model and retrieval details, tool inventory, test accounts for relevant roles, representative data, and the authorized assessment boundaries. #### How is an AI pentest different from a web application pentest? An AI assessment examines instruction boundaries, retrieved content, generated responses, and the actions available to agents. Conventional authentication, authorization, and API issues may also affect the system. We define which layers the engagement covers so there are no gaps hidden by the service label. #### Can you test an internal copilot connected to company data? Yes, within an authorized scope and suitable environment. We need to understand user roles, retrieval permissions, and tool access. Test accounts and representative data let the assessment examine whether the application respects the boundaries your business expects. #### Does a successful assessment prove the AI is completely safe? No. An assessment evaluates a defined system and scope at a point in time. New models, prompts, tools, or data sources can change its behavior. Findings should inform fixes and ongoing evaluation, with retesting of the changes that matter. Cost factors: Application complexity, user roles, retrieval sources, connected tools, environment access, and the depth of retesting determine assessment effort. Timeline: Testing begins after scope, authorization, and environment access are agreed. Complex agent actions and remediation retesting affect the engagement schedule. ### Penetration Testing URL: https://utilities.studio/services/cyber-security/penetration-testing Penetration testing is an authorised attempt to identify and validate exploitable weaknesses in a defined system. Our team tests agreed attack paths and gives your engineers evidence they can reproduce, prioritise and fix. Scope: Scope the assets, business flows and rules of engagement. Test for exploitable weaknesses and assess their business impact. Review evidence and remediation with your engineering team. Deliverables: Executive risk summary Reproducible technical findings Prioritized remediation guidance Preparation: In-scope applications, APIs and infrastructure; user roles; environment access; exclusions; and your release or audit deadline. #### What can you test? We can scope web, API, mobile, cloud, internal and external network, and thick-client assessments. Our team also tests AI and LLM systems. #### Penetration testing vs. vulnerability assessment: which do we need? A vulnerability assessment identifies and prioritises potential weaknesses. A penetration test investigates whether weaknesses can be exploited and what the impact could be within the agreed boundaries. Use the scope and business question to choose the right assessment. #### Is remediation retesting included? Retesting can be included in the engagement. We agree on the findings covered, the retest window and how fixes will be verified before testing starts. Cost factors: Asset count, application complexity, user roles, testing depth, access model and whether retesting is included. Timeline: We estimate the testing window after scoping and separate it from reporting and retesting. A small application and a multi-tenant platform require different plans. ### Vulnerability Management URL: https://utilities.studio/services/cyber-security/vulnerability-management Vulnerability management is the ongoing work of finding, prioritising, fixing and rechecking security weaknesses. Our team helps you move from a growing scan backlog to a remediation queue with clear ownership. Scope: Review asset coverage and existing scan results. Separate actionable exposure from duplicates and noise. Set remediation owners and a verification cadence. Deliverables: Prioritized vulnerability register Remediation ownership plan Verification and reporting cadence Preparation: Your asset inventory, recent scan results, existing tools and the teams responsible for applying fixes. #### Do we need to replace our scanning tools? We start with the tools and findings you already have. Any additional tooling is proposed only after reviewing coverage gaps. #### How do you prioritise vulnerabilities? Severity is a starting point. Our team also considers exposure, affected business systems, exploit evidence and available mitigations. A critical issue on an exposed service may need a different response from an isolated finding with limited impact. #### Does vulnerability management replace penetration testing? No. Ongoing vulnerability management maintains visibility and tracks remediation. Penetration testing explores attack paths and validates impact within a defined scope. The two can inform each other. Cost factors: Asset coverage, scanning frequency, validation needs, reporting requirements and remediation coordination. Timeline: The first cycle establishes coverage and a baseline. Ongoing review and verification cadence are agreed around asset changes, risk and your release process. ### Cloud Security Services URL: https://utilities.studio/services/cyber-security/cloud-security Cloud security services assess and improve the controls protecting your cloud workloads and data. Our team reviews identity, configuration, exposure and logging so your engineers know where to make changes. Scope: Assess the agreed AWS, Azure or GCP environment. Review identity permissions, exposed services and workload boundaries. Explain attack paths and practical hardening options. Deliverables: Cloud exposure assessment Permission and configuration findings Prioritized hardening plan Preparation: Cloud providers, accounts or subscriptions, an architecture outline, critical workloads and current access controls. #### Can you assess containers too? Kubernetes and Docker security can be included in the scope, along with the cloud identities, network paths and workloads they depend on. #### Is cloud security the cloud provider’s responsibility? Responsibility is shared. The provider secures parts of the underlying infrastructure; your responsibilities depend on the service you use and include how you configure access and protect your data. We scope the review around the services in your environment. #### Can you review an environment without moving it? Yes. Our team can assess an existing environment and recommend changes within it. Migration is a separate decision, not a prerequisite for a security review. Cost factors: Account count, workload complexity, identity architecture, configuration review depth and remediation support. Timeline: Timing depends on access and the breadth of workloads. We agree on the assessment window, findings review and any implementation phase separately. ### Identity and Access Management (IAM) URL: https://utilities.studio/services/cyber-security/identity-and-access-management Identity and access management controls who can access a system and what they can do. Our team helps review and improve authentication, permissions and the processes for joining, moving within and leaving your organisation. Scope: Map identities, privileged roles and sensitive resources. Review sign-in flows, service accounts and permission boundaries. Plan access reviews and practical least-privilege changes. Deliverables: Access and privilege review Identity risk findings Access lifecycle recommendations Preparation: Identity providers, important applications, role definitions, privileged accounts and joiner or leaver workflows. #### Will this include implementing a new identity provider? It can. We first review your current setup and agree whether the engagement covers assessment, configuration changes or a wider identity integration. #### Authentication vs. authorisation: what is the difference? Authentication establishes who a user or service is. Authorisation determines what that identity may do. A secure login alone does not prevent someone from accessing another user’s records; permissions need their own design and testing. #### Can you improve IAM without replacing our identity provider? Often, yes. Our team starts with the current provider, roles and integration constraints. We recommend replacement only when the existing setup cannot meet the agreed requirements. Cost factors: Application count, identity sources, role complexity, federation requirements and migration work. Timeline: An assessment can precede implementation. Rollout timing depends on integrations, testing, recovery access and the risk of disrupting legitimate users. ### Threat Intelligence URL: https://utilities.studio/services/cyber-security/threat-intelligence Threat intelligence puts information about threats into the context of your organisation. Our team helps you identify relevant adversary activity and translate it into monitoring priorities, investigations and business decisions. Scope: Define the assets, technologies and threat questions to investigate. Review relevant public intelligence and exposure signals. Connect findings to detection, testing and remediation priorities. Deliverables: Relevant threat briefing Exposure and attack-path context Recommended defensive actions Preparation: Your sector, critical assets, current intelligence sources, security tools and the decisions your team needs to make. #### What makes the reporting specific to our business? The scope starts with your assets, technologies and risk questions. Findings should explain their relevance to that environment and the action your team can take. #### Strategic vs. tactical threat intelligence: which is useful? Strategic intelligence supports decisions about business exposure and investment. Tactical intelligence supports detection and investigation of adversary activity. Start with the decision or workflow you need to improve, then choose the information and reporting format. #### Will adding more threat feeds improve our security? Not necessarily. Information is useful when it is relevant, assessed and connected to an action. Our team focuses on the context your analysts and risk leaders need, rather than adding alerts without a clear owner. Cost factors: Intelligence requirements, sources, analysis depth, reporting cadence and integration into security workflows. Timeline: The first step defines intelligence requirements. Research and reporting cadence then follow the agreed use cases rather than an arbitrary volume of feeds. ### iOS Apps URL: https://utilities.studio/services/app-development/ios-apps iOS app development takes an iPhone or iPad product from user journeys through implementation, testing and release preparation. Our team connects the app to the accounts, data and services it needs to work in everyday use. Scope: Prototype the main journeys and device interactions. Build the app, backend connections and agreed payment flows. Test on devices and prepare App Store submission. Deliverables: Working iOS app Tested integrations Store submission support Preparation: Your core user journey, designs if available, backend integrations, target devices and Apple developer account arrangements. #### Can you integrate subscriptions? Yes. Subscription design and implementation can be scoped with the app, including account state, purchase flows and the applicable store requirements. #### Native vs. cross-platform iOS development: how do we choose? The choice depends on device features, interaction requirements, your Android plans and maintenance capacity. Our team considers those constraints before recommending an approach. Sharing code does not remove the need to test platform-specific behaviour. #### Can you guarantee App Store approval? No. Our team can prepare builds, submission information and fixes for review feedback within scope. Apple reviews the app against its guidelines and makes the approval decision. Cost factors: Screen and workflow complexity, device integrations, backend work, payments and release support. Timeline: A release plan follows discovery. Prototyping, development, device testing and submission are separate milestones; Apple controls the store review decision and timing. ### Android Apps URL: https://utilities.studio/services/app-development/android-apps Android app development covers the interface, application logic, device behaviour and release work behind an Android product. Our team builds around the devices your customers use and the services your business depends on. Scope: Define supported devices and the core user journeys. Build Android interactions and backend integrations. Test important device scenarios and prepare the Play Store release. Deliverables: Working Android app Device testing plan Play Store submission support Preparation: Your user journeys, target device range, required permissions, backend services and Play Console account arrangements. #### How do you handle different Android devices? We agree on supported versions, device types and the test matrix during planning, then prioritize the configurations that matter for your audience. #### How do you test across Android devices? We agree on supported Android versions and a representative device set. Testing covers key journeys, screen sizes, permissions and relevant network or background behaviour. The test plan follows your audience rather than promising every possible device. #### Can you build Android alongside an existing iOS app? Yes. Our team can review the existing product and backend, preserve the important workflows and adapt the experience for Android. Shared business logic and platform-specific work are scoped together. Cost factors: Device support, offline behaviour, integrations, backend requirements and store submission work. Timeline: Timing depends on the first-release scope and testing matrix. Store review is an external step; we plan submission preparation separately from development completion. ### Front-end development URL: https://utilities.studio/services/fullstack-development/front-end-development Front-end development builds the part of a website or application people see and use. Our team turns designs into responsive interfaces, connects them to your APIs and tests the journeys that matter to your customers. Scope: Translate designs into responsive components. Connect real data and handle loading, empty and error states. Review keyboard access, browser behavior and page performance. Deliverables: Responsive frontend Reusable components Browser and accessibility checks Preparation: Design files, existing components, API contracts, supported browsers and accessibility requirements. #### Can you work within our design system? Yes. We can extend existing components, document new patterns and keep the implementation consistent with your established interface. #### Does React or Vue make a website accessible automatically? No. Accessibility depends on the interface you build: semantic structure, keyboard access, focus, labels and understandable feedback. Our team scopes accessibility requirements and combines automated checks with manual interaction testing. #### Can you improve performance without redesigning everything? Yes. Our team can investigate loading, rendering and interaction bottlenecks, then propose targeted changes. We measure the affected pages before and after the work instead of assuming a new framework will solve it. Cost factors: Page and component count, interaction complexity, design readiness, API integration and browser coverage. Timeline: We plan delivery around reviewable screens and complete user journeys. Missing designs or unstable API contracts can affect the schedule and are identified early. ### Back-end development URL: https://utilities.studio/services/fullstack-development/back-end-development Back-end development builds the logic, data access and services behind your product. Our team designs and implements the workflows that make accounts, payments, integrations and other business operations reliable. Scope: Define business rules and service boundaries. Implement authentication, workflows and background processing. Add meaningful tests, logging and operational documentation. Deliverables: Backend services Tested business workflows Operating documentation Preparation: Existing architecture, business rules, integration requirements, expected workload and deployment constraints. #### Can you modernize an existing backend? Yes. We can assess the current services and plan incremental improvements around stability, performance and compatibility. #### Which backend language should we use? The right choice depends on your existing stack, workload, team skills and operational constraints. Our team evaluates those factors before recommending Node.js, Python, Java, Ruby, PHP or another suitable option. #### Can you modernise a backend without a full rewrite? Often, yes. Our team can isolate a slow or difficult part of the system, define its interfaces and replace it incrementally. The migration plan needs compatibility checks, observability and a way to roll back. Cost factors: Business logic complexity, integrations, data migration, security requirements and operational readiness. Timeline: We break delivery into usable service boundaries and tested workflows. Integration access, migration requirements and review cycles shape the final schedule. ### Database design and management URL: https://utilities.studio/services/fullstack-development/database-design-and-management Database design and management shapes how your product stores, retrieves and protects its data. Our team works on schemas, queries, migrations and operational routines so data remains useful as the product changes. Scope: Map entities, access patterns and data constraints. Design schemas, indexes and safe migration steps. Review backup, recovery and performance requirements. Deliverables: Documented data model Migration and indexing plan Query and recovery recommendations Preparation: Schema or data model, slow queries, expected data growth, backup arrangements and migration constraints. #### Can you improve an existing database? Yes. We review the current model, slow queries and operating constraints before proposing changes or migrations. #### SQL vs. NoSQL: which database is right for us? Start with your data relationships, query patterns, consistency needs and operating constraints. Relational and non-relational databases solve different problems; neither is automatically faster or more scalable for every workload. #### Can you migrate our database without downtime? Downtime requirements need to be assessed against the source, target and application architecture. Our team can scope approaches to reduce interruption, but a zero-downtime commitment requires a verified migration plan. Cost factors: Data model complexity, query tuning, data volume, migration risk and operational support. Timeline: Assessment, schema changes and migration are planned separately. Large or sensitive migrations need rehearsal, validation and an agreed recovery approach. ### API creation and integration URL: https://utilities.studio/services/fullstack-development/api-creation-and-integration API development and integration connects systems through defined interfaces. Our team builds APIs and connects third-party services with clear contracts, access controls and handling for errors, retries and changes. Scope: Define endpoints, schemas and access rules. Implement integrations with validation and error handling. Test contracts, retries and important failure scenarios. Deliverables: Documented API contracts Working integrations Integration tests Preparation: API documentation, sandbox access, data flows, authentication requirements and expected request volumes. #### Can you connect third-party services? Yes. We review the provider API, authentication, rate limits and webhook behavior, then scope the integration and its failure handling. #### REST vs. GraphQL: which should we choose? REST commonly exposes resources through endpoints. GraphQL lets clients request fields through a typed schema. The choice depends on clients, data relationships, caching and operational complexity, not which approach is newer. #### How do you handle API failures and rate limits? Our team designs error handling around the provider’s contract and the business operation. That can include timeouts, bounded retries, idempotency, queues and useful logs. Retrying every failed request blindly can create duplicate work. Cost factors: Endpoint and integration count, data mapping, provider limits, authentication and failure handling. Timeline: Integration timelines depend on working credentials, provider behaviour and data quality. We verify the important flows early and allow time for end-to-end testing. ### Cloud deployment and hosting URL: https://utilities.studio/services/fullstack-development/cloud-deployment-and-hosting Cloud deployment and hosting work takes software into an environment where it can be released, monitored and maintained. Our team helps configure infrastructure, delivery workflows and the operational checks behind a production release. Scope: Review hosting needs and environment boundaries. Set up build, release and rollback workflows. Configure agreed monitoring, backups and access controls. Deliverables: Deployment configuration Release and rollback runbook Operational monitoring setup Preparation: Current environments, cloud accounts, deployment steps, workload expectations and recovery requirements. #### Will you choose the hosting provider? We can recommend a provider after reviewing your existing stack, traffic, reliability needs and operating budget. #### How is deployment different from ongoing hosting support? Deployment establishes how software reaches an environment. Ongoing support covers agreed operational work after release, such as updates, monitoring or incident handling. We define these responsibilities separately so ownership is clear. #### Will moving to the cloud automatically lower our costs? No. Costs depend on architecture, usage, service selection and operating practices. Our team can review those drivers and propose changes; savings need to be checked against real billing and workload data. Cost factors: Environment count, infrastructure complexity, migration work, availability needs and ongoing support. Timeline: We assess the current setup before scheduling a release or migration. Validation, recovery checks and rollback planning are part of the agreed delivery scope. ### UI/UX prototyping and wireframing URL: https://utilities.studio/services/fullstack-development/ui-ux-prototyping UI/UX prototyping makes a proposed product experience tangible before full development. Our team maps user journeys, creates wireframes and builds prototypes that help your team review decisions and test assumptions. Scope: Map the people, tasks and constraints behind the product. Wireframe the important journeys and alternate states. Develop a prototype and an implementation handoff. Deliverables: User flows Wireframes and prototype Design handoff Preparation: The users and task you are designing for, existing research, product constraints and the decisions you need to test. #### Can we start with a rough idea? Yes. We can help define the problem, clarify the audience and narrow the first release before moving into detailed design. #### Wireframe vs. prototype: what is the difference? A wireframe describes a screen’s structure and content priorities. A prototype connects screens or interactions to demonstrate a flow. Neither is the finished application; each helps answer different design questions before implementation. #### What do developers receive at handoff? The agreed handoff can include screen designs, component states, interaction notes and responsive behaviour. Our team identifies unresolved decisions so developers can distinguish approved work from ideas still being tested. Cost factors: Journey count, design fidelity, research or testing needs and the number of review rounds. Timeline: A focused flow can be planned independently of a full product. We agree on the questions the prototype must answer and the review milestones before design begins. ### Website maintenance and optimization URL: https://utilities.studio/services/fullstack-development/website-maintenance Website maintenance keeps an existing website usable as content, dependencies and business needs change. Our team investigates issues, applies agreed updates and checks the customer journeys affected by the work. Scope: Review performance, defects and maintenance priorities. Implement agreed fixes and content or feature updates. Verify important journeys and document the changes. Deliverables: Maintenance priorities Verified fixes and updates Performance recommendations Preparation: Your site URL, technology stack, access arrangements, known issues and the journeys that generate enquiries or sales. #### Is ongoing support available? Yes. We can agree on a recurring scope with clear priorities, ownership and response expectations. #### What should a website maintenance plan include? Define the systems covered, update responsibilities, backup checks, monitoring, support hours and how changes are requested. Content work, hosting fees and feature development should be explicitly included or excluded in the scope. #### Can you maintain a website another agency built? Yes, subject to a technical review and suitable access. Our team checks the code, dependencies and deployment process before taking on changes, then documents any constraints that affect ongoing support. Cost factors: Site complexity, update frequency, integrations, support coverage and the volume of requested changes. Timeline: We prioritise an initial backlog, then agree on a maintenance cadence. Urgent support commitments depend on the engagement; a discovery call does not establish an SLA. ### Version control management URL: https://utilities.studio/services/fullstack-development/version-control-management Git and GitHub consulting helps teams make software changes through a clear, reviewable process. Our team improves repository structure, pull requests, release workflows and the checks that protect shared branches. Scope: Review branches, permissions and the release process. Define pull request checks and review responsibilities. Document everyday development and recovery workflows. Deliverables: Git workflow guidance Repository checks and permissions Team handoff documentation Preparation: Repository structure, team permissions, current pull request process, CI checks and release steps. #### Can you improve our workflow without moving repositories? Yes. We start with the repository and tooling you already use and focus on practical changes your team can adopt. #### What do GitHub branch protection rules do? Branch protection can require reviews and status checks before changes are merged, and restrict certain changes to important branches. The available controls depend on the repository and plan. Rules support a workflow; they do not replace meaningful code review. #### Can you add CI checks without slowing every release? Our team can separate quick checks from longer jobs and run the right checks for each change. The goal is useful feedback before a merge, with failures that your developers can understand and act on. Cost factors: Repository count, permission structure, automation requirements and workflow migration. Timeline: We review the current process, pilot changes and document the workflow. Rollout timing depends on team availability and the number of repositories affected. ### Security implementation URL: https://utilities.studio/services/fullstack-development/security-implementation Application security implementation builds protections into the software itself. Our team works on authentication, permissions, transport security, data handling and other controls, with tests for the behaviour those controls are meant to enforce. Scope: Review sensitive data, user roles and trust boundaries. Implement agreed authentication, TLS and encryption controls. Test access restrictions and document security assumptions. Deliverables: Implemented security controls Access control tests Security configuration guidance Preparation: Application architecture, sensitive data flows, login and permission models, existing findings and deployment constraints. #### Does this replace a penetration test? Implementation and independent assessment serve different purposes. A penetration test can be scoped separately to evaluate how the finished controls hold up. #### Is HTTPS enough to secure an application? No. HTTPS protects data in transit, but it does not resolve broken permissions, unsafe input handling or exposed secrets. Our team considers these controls together, based on the application and its threat model. #### How do you verify that a security fix works? Our team tests the intended control and relevant failure cases. For a permission change, that includes requests that should be allowed and denied. Independent penetration testing can provide an additional assessment with its own scope. Cost factors: Control gaps, application complexity, identity integrations, data handling and verification needs. Timeline: We prioritise the controls by risk and implementation dependencies. Changes to identity or data handling need regression testing across affected user journeys. ### CMS customization URL: https://utilities.studio/services/fullstack-development/cms-customization CMS customisation adapts a publishing or commerce platform to your business. Our team works on WordPress and Shopify themes, content structures and integrations so the people running the site can manage their everyday work. Scope: Map content types, editorial tasks and commerce needs. Customize templates, permissions and integrations. Test publishing flows and train the people using them. Deliverables: Customized CMS experience Templates and integrations Editor handoff guide Preparation: Current site, publishing or store workflows, theme and app dependencies, integrations and migration needs. #### Can you preserve our existing content? Yes. We review the current content, URLs and integrations and plan any migration around preserving what the site depends on. #### WordPress vs. Shopify: which platform fits our project? Start with the core workflow. WordPress offers a flexible publishing foundation; Shopify focuses on commerce. Content needs, checkout requirements, integrations, ongoing costs and your team’s editing workflow guide the decision. #### Will our team be able to edit content without a developer? That is part of the brief. Our team can configure editable content fields, reusable sections and suitable permissions, then document the publishing workflow. Custom functionality may still need development support. Cost factors: Template count, content structures, integration work, catalogue complexity and migration requirements. Timeline: We plan around the templates and workflows in scope. Migration also needs content validation, redirect planning and checks of publishing or purchase journeys. ## Differentiation - Talk through the real problem. What needs to change? Who is it for? We work through the goals, constraints, and open questions before choosing a solution. - Make the plan concrete. Agree on the scope, deliverables, responsibilities, and checkpoints. You should know what you are buying and how we will review it. - Build, review, and refine. Review working versions as the project takes shape. Test the important journeys, resolve the rough edges, and prepare the handoff together. ## Case Studies - [GrowthDay](https://utilities.studio/work/growthday) (Product engineering): Credit: Hariom Sharma's full-time engineering work at GrowthDay, January 2021 to April 2026. Results reported in his portfolio. Source: https://hariom.cc/work/growthday/. Problem: Growing a personal development platform meant rebuilding its frontend, improving mobile checkout and giving the enterprise product room to grow. Built: Engineering for a platform that grew to 400K+ users. Metrics: 400K+ Platform users, +9% Checkout conversion improvement, 25% Lower payment failure rate, 20x Infrastructure scalability. - [Appointy](https://utilities.studio/work/appointy) (SaaS platform engineering): Credit: Hariom Sharma's full-time career work at Appointy, 2015 to 2021. Google and Telefónica were deployments of the Appointy platform. Results reported in his portfolio. Source: https://hariom.cc/work/appointy/. Problem: One reusable SaaS foundation replaced repeated product setup work and brought scheduling pages down from 15 seconds to under a second. Built: Scheduling infrastructure for more than a million users. Metrics: 1M+ Users served, 15s to <1s Page load time, 232 Reusable packages, 19 Language options. - [House of Manifestation](https://utilities.studio/work/house-of-manifestation) (Web and mobile product): Credit: Shan Kulkarni's work as senior engineer on contract, January to March 2026. Launch figures reported in his portfolio. Source: https://shankulkarni.com/work/house-of-manifestation/. Problem: A basic Kajabi setup became a web and mobile product with a course library, subscription store and the systems to track what happened after launch. Built: A community product, live on web and mobile in three months. Metrics: 3 months Brief to production, ~500 Members at launch, 5.0 iOS rating at launch, 4 Platforms delivered. - [VWO Deploy](https://utilities.studio/work/vwo-deploy) (B2B product explainer): Credit: Soaham Dixit's portfolio work for VWO. Campaign results reported in his portfolio. Source: https://soahamdixit.com/. Problem: A website change could not wait for the developer to return. That everyday problem gave VWO Deploy a clear reason to matter before the feature walkthrough began. Built: A product story with a reported 6.5% trial conversion rate. Metrics: 6.5% Trial conversion rate, $720K Reported pipeline, 420 Leads, 68% Retention. - [Artwork Flow](https://utilities.studio/work/artwork-flow) (Animated product explainer): Credit: Soaham Dixit's portfolio work for Artwork Flow. Campaign results reported in his portfolio. Source: https://soahamdixit.com/. Problem: An overwhelmed creative team gave a specialized operations product a recognizable starting point. The explainer showed how the work could become more manageable in under 90 seconds. Built: Making creative operations easier to understand in 90 seconds. Metrics: 6.2% Conversion rate, $560K Reported pipeline, 360 Leads, 64% Retention. - [Tontine](https://utilities.studio/work/tontine) (Guided product demo): Credit: Soaham Dixit's portfolio work for Tontine. Campaign results reported in his portfolio. Source: https://soahamdixit.com/. Problem: A narrated walkthrough gave e-commerce merchants a concrete way to understand automated price testing and see the product in use. Built: A pricing product demo with a reported 9.5x ROAS. Metrics: 9.5x Return on ad spend, 6.0% Conversion rate, $540K Reported pipeline, 320 Leads. - [Truecaller for Business](https://utilities.studio/work/truecaller) (B2B product explainer): Credit: Soaham Dixit's portfolio work for Truecaller for Business. Campaign results reported in his portfolio. Source: https://soahamdixit.com/. Problem: A familiar caller ID product needed a clear business explanation. The video centered on verified business calls and the value a buyer could understand without a technical background. Built: Turning a familiar brand into a business case. Metrics: $200K Attributed pipeline, 150 Leads, 3.7% Conversion rate, 53% Retention. - [The security practice](https://utilities.studio/work/security-practice) (Security practice profile): Credit: Sheeraz Ali's professional background. These are his reported career figures across roles and research, not a single client engagement or Utilities Studio totals. Source: https://sheerazali.com/. Problem: Our Head of Cybersecurity brings experience in AI and LLM testing, application security and cloud assessments, alongside security research and technical lab development. Built: Security experience built across 245 penetration tests. Metrics: 245 Personal pentesting engagements, 1,592 Vulnerabilities identified, 28+ CVEs discovered, 300+ Hack The Box machines and labs. ## In-House Products - Vouch (Trial Abuse Prevention): Reduce trial abuse with email validation, device fingerprinting and IP risk signals. Vouch gives your signup flow an allow, flag or block recommendation. Technologies: Cloudflare Workers, Cloudflare KV, D1, Supabase, Stripe. URL: https://vouch.expert/ - Aviater (Aviation | Flight Operations SaaS): Bring crew readiness, aircraft status and route requirements into one flight-release decision. Aviater helps aviation operators find blockers and keep a traceable record. Technologies: TanStack Start, React 19, Supabase, Cloudflare Workers. URL: https://aviater.io/ - Jetseen (Travel | Tax Residency Compliance): Track your days across countries, see time remaining under residency and visa rules, and keep a travel record you can review and export. Technologies: React Native, iOS, Android. URL: https://apps.apple.com/app/jetseen/id6759822501 - My Trainer Connect (Fitness marketplace): Find a trainer who fits your goals and schedule. Explore programs, message your trainer and track your progress in one place. Technologies: Trainer matching, Training programs, Messaging. URL: https://mytrainerconnect.com/ - Prompt Valley (AI prompt library): Explore prompt templates for ChatGPT, Gemini and image models. Find a starting point for your next piece of writing, image or creative project. Technologies: Text prompts, Image prompts, Prompt templates. URL: https://promptvalley.ai/ - Becoming: Private Journal (Private journaling): A quiet space for daily reflection on iPhone. Write with guided prompts, track your mood, add photos and protect your journal with Face ID or Touch ID. Technologies: Guided reflection, Mood tracking, Biometric lock. URL: https://apps.apple.com/in/app/becoming-private-journal/id6777809207 ## Open Source - dotclaude (Claude Code Plugin): An installable collection of Claude Code skills, specialist agents, commands, and coding conventions. Covers scaffolding, interfaces, authentication, deployment, and testing. Technologies: TypeScript, Shell, Bun. Repository: https://github.com/harryy2510/dotclaude - RN-Lib-Claude (Claude Code Plugin): A Claude Code plugin for building React Native libraries. Includes scaffolding, native module code generation, animations, testing, and release workflows using New Architecture patterns. Technologies: TypeScript, React Native, Bun. Repository: https://github.com/Shankulkarni/RN-Lib-Claude - vibe-pilot (AI Automation): Connects to vibe-kanban to organize tasks and route implementation work to AI coding agents. Classifies incoming work and starts workspaces that can prepare changes and pull requests. Technologies: TypeScript, Bun, Claude API. Repository: https://github.com/harryy2510/vibe-pilot - Crash-Pilot (AI Automation): Connects Firebase crash reports to a code investigation. Traces call paths, attempts fixes with Claude Code, and prepares pull requests with a root cause analysis for review. Technologies: Python, Claude Code, GitHub Actions. Repository: https://github.com/Shankulkarni/Crash-Pilot - geocoded (Free API): A geolocation API for countries, states, cities, and IP lookup. Built on Cloudflare Workers with full-text search, field selection, pagination, and edge caching. Technologies: TypeScript, Cloudflare Workers, D1. Repository: https://github.com/harryy2510/geocoded - react-native-country-state-city-picker (React Native): A country, state, and city picker for React Native, powered by the geocoded.me API. Includes headless hooks, render props, design tokens, and caching for repeated requests. Technologies: TypeScript, React Native, New Architecture. Repository: https://github.com/Shankulkarni/react-native-country-state-city-picker ## Team - Hariom Sharma, Co-founder · Product engineering: Staff frontend and full-stack engineer with 10+ years of experience. Led engineering at GrowthDay and built scheduling infrastructure at Appointy. URL: https://hariom.cc/ - Shan Kulkarni, Co-founder · Product engineering: Engineer working across product, mobile, and AI. His portfolio includes GrowthDay, enterprise scheduling, and House of Manifestation. URL: https://shankulkarni.com/ - Soaham Dixit, Co-founder · Video marketing: Video director and strategist for B2B SaaS. His work includes product explainers, demos, and campaigns for VWO, GrowthDay, Atlan, and Truecaller. URL: https://soahamdixit.com/ - Sheeraz Ali, Head of cybersecurity: Offensive security researcher and penetration tester. His experience covers AI systems, cloud, applications, and security research. URL: https://sheerazali.com/ ## Machine-Readable Resources - LLM summary: https://utilities.studio/llms.txt - Structured index: https://utilities.studio/site-index.json - RSS: https://utilities.studio/rss.xml - Sitemap: https://utilities.studio/sitemap-index.xml ## Blog Posts ### Decide what your first app release needs to prove URL: https://utilities.studio/blog/planning-your-first-app-release Published: 2026-09-10T00:00:00.000Z Tags: mobile, product Description: A practical way to narrow a mobile app brief around one complete user journey, its dependencies and the release work. An app brief can grow quickly. Accounts lead to profiles. Profiles lead to messaging. Messaging leads to notifications. Soon the first release contains every feature the business might need. Before choosing the feature list, write down what the first release needs to prove. Be specific enough that the answer changes what you build. ## Choose one journey that reaches a useful result "Users can sign up" describes a step. "A client can find a trainer, choose a program and begin the first session" describes a useful result. Map that journey from the first screen to the outcome. Include the points where the user might need help, leave the app or wait for another person. Those moments often reveal work that a screen list misses. Then separate what the journey requires from what could improve it later. ## Account for the system behind the screens A mobile interface may depend on payments, account permissions, content, notifications and support processes. A polished prototype does not answer how those pieces will work in production. For each dependency, identify who owns it and what already exists. If the business has a working backend, understand its constraints before designing interactions it cannot support. If people will manage content or customer requests manually at launch, describe that process too. The first release needs an operating plan as well as a build plan. ## Make platform choices around the experience Launching on iOS and Android together may be appropriate. Starting with one platform may also fit the audience and the available scope. The choice should follow the product, the devices customers use and the features the app needs. Discuss device capabilities and platform integrations early. Camera use, location, offline behavior and purchases can affect how the experience is implemented and tested. ## Put release preparation in the plan Store submission is part of delivery. Screenshots, descriptions, privacy disclosures, support details and review access all need owners. Keep the release scope explicit. Agree on supported devices, acceptance checks and what happens if a store review requires changes. The stores control their review decisions, so avoid building the business plan around an assumed approval date. ## Keep the next decision visible Before launch, decide what feedback will help you choose the next piece of work. It could be where people abandon the main journey, which requests reach support or what returning users try to do next. A first release is easier to evaluate when everyone knows the question it was built to answer. [Explore app development at Utilities Studio](/services/app-development). ### What to bring to a penetration testing scoping call URL: https://utilities.studio/blog/scoping-a-penetration-test Published: 2026-09-10T00:00:00.000Z Tags: security, planning Description: The systems, user journeys and business questions that help turn a broad request into a useful security assessment. A request to "test our application" is a starting point. Before testing begins, both teams need a shared understanding of the systems involved, the boundaries of the work and the decisions the results should support. You do not need a polished security brief for the first call. Bring the information you have, and identify what still needs an owner. ## Start with the reason for the test A launch, a customer review and a concern about account isolation may lead to different testing priorities. Explain what prompted the request and what your team needs to know when the assessment ends. If there is a deadline, describe what happens on that date. A report needed for a procurement review is different from a release that can move while a serious finding is fixed. ## Describe the product as people use it Bring a short list of the important journeys. For a SaaS product, that might include account creation, inviting colleagues, changing roles and exporting customer data. For an API, explain who calls it and which actions involve sensitive information. Include the roles available in the system. Testing a single administrator account gives a different view from testing the boundaries between ordinary users, administrators and separate customer accounts. A diagram helps, but a clear conversation is enough to get started. ## Agree on the testing boundaries List the applications, APIs, domains and environments you expect to include. Identify third-party systems and anything your organization cannot authorize for testing. The rules of engagement should cover permitted techniques, excluded activities, working hours, contact points and the circumstances that require testing to stop. These details deserve agreement before anyone starts sending traffic. ## Prepare access and a contact path Decide who will create test accounts, answer product questions and handle an urgent finding. If the test depends on a staging environment, discuss how closely it represents the system you want assessed. Access problems can consume time that should be spent investigating the product. It helps to verify accounts and permissions before the testing window starts. ## Ask what you will receive A useful handoff should explain the finding, the evidence behind it and the practical next action. Ask about the report format, the technical review meeting and whether retesting is included in the proposed scope. Your engineers need enough detail to investigate. Your decision-makers need to understand the impact and the choices in front of them. Agree on both audiences at the start. [Discuss a penetration test with Utilities Studio](/services/cyber-security/penetration-testing). ### What a production handoff should include URL: https://utilities.studio/blog/what-a-production-handoff-should-include Published: 2026-09-10T00:00:00.000Z Tags: engineering, delivery Description: The access, release instructions and operating context a team needs to keep a product running after launch. A repository is part of a handoff. The people responsible for the product also need to know how to release it, recognize a problem and recover from a change that goes wrong. Agree on the handoff while planning the work. It is harder to reconstruct operating knowledge when the people who built the system have already moved on. ## Make ownership explicit List the services the product depends on: hosting, domains, email, payments, analytics and any external APIs. Record who owns each account and who should receive billing or operational notices. Check that the right people have access. Keep secrets in the appropriate secret-management system rather than copying them into a general handoff document. ## Write down the release path Someone who did not build the deployment pipeline should be able to follow the release instructions. Document the checks that must pass, how a change reaches production and how the team verifies that the release worked. Explain how database changes fit into that process. A code rollback alone may not reverse a data migration, so the recovery plan needs to account for both. ## Explain how to recognize trouble Name the signals the team should watch and the person responsible for responding. A dashboard is useful only if someone understands what requires attention. Include the location of logs, the important alerts and the dependencies that can affect customer journeys. Record known limits so the next team does not have to rediscover them during an incident. ## Cover recovery before it is needed Document what is backed up, where it is stored and how restoration is expected to work. If restoration has been tested, record the procedure and the result. If it has not, make that unfinished work visible. The same principle applies to rollback instructions. Distinguish a procedure someone has verified from an assumption that still needs testing. ## Leave the product context with the code Explain the decisions that would otherwise look arbitrary: why a service was chosen, which tradeoffs were accepted and which features have known constraints. Keep this concise enough for the next engineer to use. A short walkthrough helps connect the documentation to the working system. Give the receiving team time to ask questions and complete a release or another agreed operating task themselves. The handoff is complete when the next team can take responsibility with a clear view of the system and the work still ahead. [Explore full-stack development at Utilities Studio](/services/fullstack-development). ### Hello from Utilities Studio URL: https://utilities.studio/blog/hello-world Published: 2026-04-30T06:00:00.000Z Tags: studio, product, engineering Description: Why we are publishing notes on product strategy, AI-assisted execution, and production software delivery. We build products for teams that need experienced ownership without turning the work into a hiring project. This blog is where we will publish the practical side of that work: how we shape ideas, design product systems, use AI in delivery, make architecture decisions, and keep production software moving after launch. ## What to expect Short notes from real delivery work. - Product strategy that turns fuzzy scope into something shippable. - Engineering decisions that hold up after the first release. - AI-assisted workflows that improve speed without lowering the bar. - Lessons from designing, building, launching, and scaling products. No generic playbooks. No bloated code walkthroughs. Just clear notes from building useful software. ## How this blog works The site uses Astro content collections with MDX. Each post is a committed file with typed frontmatter, so publishing stays simple and reviewable. Future posts can use local Astro components, tables, links, and lightweight visuals without adding a CMS or client-side framework.