Set Project Stack
An agency’s “project stack” is the set of tools and systems used to build and run a specific engagement: repositories, CI/CD, issue tracking, design tools, analytics, and deployment targets. A “client stack” is what the client already runs: EHR or scheduling systems, CRM, identity provider, data warehouse, content systems, and any compliance controls. The project stack and client stack meet at integration points like APIs, SSO, webhooks, file transfers, and reporting exports.
For health-adjacent work, the stack choice affects more than delivery speed. It shapes data flow, audit trails, access control, retention, and how easily you can answer “where did this data go?” after a month of iterations. A practical example: if an agency uses a staging environment that mirrors production, the staging data handling rules must match the client’s expectations, or the audit story breaks.
Readers who evaluate proposals often focus on deliverables like “a dashboard” or “a patient portal page.” The more revealing question is what systems power the dashboard: which database, which identity layer, which logging, and which data transformations. I once saw a team ship a report that looked correct, then discovered the metric definition lived in a spreadsheet shared via email—an approach that rarely survives a handoff.
Main Problems Or Pain Points
Agencies and clients often get stuck when they treat the stack as a technical detail instead of a governance problem. A common mistake is assuming that “we’ll just export data” solves integration. Exports can bypass fine-grained permissions, create duplicate datasets, and complicate retention schedules.
Another recurring pain point is unclear ownership of identity and access. If the client uses SSO (for example, SAML or OIDC) and the agency uses separate accounts for testing, you can end up with inconsistent access rules. That inconsistency shows up later as missing audit logs or broken role-based access when a user’s group membership changes.
Supporting technologies also create hidden dependencies. A web app might depend on a tag manager, a feature flag service, a logging pipeline, and a consent layer. If any one of those is configured differently between environments, you can get mismatched analytics, incomplete event trails, or consent records that do not match the user journey. Even the versioning of dependencies matters; a team that upgraded a front-end library on 2025-02-14 and forgot to pin the lockfile can produce hard-to-reproduce behavior.
Finally, people often underestimate how stack decisions affect incident response. If the agency’s monitoring only covers the front-end and not the API layer, you lose visibility when errors originate in upstream systems. When the client asks for a post-incident report, the agency may have logs but not the correlation IDs needed to connect requests across services.
Solutions And Advice
Map Data Flows Before Tools
Start with a data-flow map that names each dataset, its source system, and its destination. Include where data is transformed, where it is stored, and how long it remains in each environment. For health contexts, align this map with the client’s privacy and security requirements and with applicable regulations such as HIPAA in the United States when protected health information is involved.
Practically, ask the agency to describe the integration mechanism: API calls, ETL jobs, webhooks, or file transfers. Then ask what logs capture the integration events and how access to those logs is restricted. A realistic outcome to aim for is a map that can be reviewed in one working session and updated after each major integration change.
Tooling that helps includes a simple diagramming approach (even a shared document) and a checklist for data classification. If the agency uses a ticketing system like Jira, require that each integration change links to a ticket that references the data-flow update. Which, frankly, most teams skip when deadlines tighten.
Align Identity And Permissions
Define who owns authentication and authorization. If the client uses an identity provider, require SSO integration using the same protocol the client supports (SAML or OIDC are common). Specify how roles map to app permissions and how group membership changes propagate.
Ask for a test plan that covers at least: new user provisioning, role change, role removal, and session expiration. For outcomes, you can request evidence that the agency can reproduce permission behavior in a staging environment and that the client can audit access events.
In many engagements, the agency will use a service account for background jobs. That account should have the minimum permissions needed and should be rotated on a schedule agreed with the client. If the agency proposes “temporary admin access,” insist on a time-bound exception with logging and a removal date.
Set Environment And Release Rules
Separate development, staging, and production with explicit configuration differences. Require that secrets are managed through the client’s preferred secret store or through an agreed mechanism, and that the agency does not hardcode credentials in repositories. Pin dependency versions and document the upgrade policy.
Ask how releases work: CI/CD pipeline steps, rollback strategy, and how database migrations are handled. A realistic target is a rollback procedure that can be executed within minutes for a front-end change, and a documented migration plan for back-end changes. If the agency cannot describe rollback behavior, you will likely learn about it during an incident.
One small detail that matters: confirm whether the agency uses feature flags and how they are tested. I’ve seen teams ship a feature behind a flag, then forget to remove the flag after go-live, leaving dead code paths that complicate later audits.
Plan Reporting, Audits, And Handover
Decide how reporting will be produced and who owns the metric definitions. For dashboards, specify the data source, refresh cadence, and the transformation logic. If the agency uses a BI tool, clarify whether it connects directly to the client’s warehouse or relies on extracted copies.
For audits, require an evidence package: access logs, deployment logs, integration logs, and documentation of configuration. The handover should include runbooks for common failures, a list of environment variables, and a dependency inventory. A reasonable outcome is that a new engineer can reproduce the deployment in a day without contacting the agency for every step.
When the agency uses analytics events, require a schema with event names, properties, and consent handling rules. If the schema is “tribal knowledge” in a chat thread, the client will struggle to maintain it after the engagement ends.
Case Examples
Scheduling App With SSO
An anonymized clinic hires an agency to build an appointment scheduling web interface. The client already uses an identity provider for staff accounts and a scheduling backend with an API. The agency proposes a project stack with a front-end repository, a CI pipeline, and a staging environment.
The agency maps data flow for appointment metadata and user identity claims, then aligns role permissions so only staff roles can view certain appointment details. During testing, the team verifies that role removal immediately blocks access and that audit logs capture both the login event and the denied request. The engagement succeeds because the integration plan includes correlation IDs across the front-end, API gateway, and logging service.
Patient Education Content With Analytics
An anonymized health system asks an agency to create a patient education content site and track engagement. The client requires consent-aware analytics and strict retention rules for event logs. The agency’s project stack includes a content system integration and an analytics pipeline.
The agency defines an event schema that separates “page view” from “download” actions and records consent state as a property. The client reviews the retention schedule for raw events and aggregated reports, then approves a process where raw logs are deleted after a set period while aggregated metrics remain. The project avoids a common failure mode where analytics are configured without a consent mapping, leading to reports that cannot be defended during a privacy review.
Comparison Table Or Checklist
Use the checklist below to compare proposals for an agency engagement. The goal is decision support, not promotion.
| Evaluation Area | What To Ask | Good Sign | Red Flag |
|---|---|---|---|
| Data Flow | Which systems send and receive each dataset? | A named map with transformations and retention per environment | “We’ll export and clean later” with no retention plan |
| Identity | Who owns SSO and role mapping? | SSO integration with test cases for role changes | Separate agency accounts for production-like testing |
| Release Process | How do you roll back and manage secrets? | Documented rollback and secret handling with pinned dependencies | No rollback plan; credentials in config files |
| Audit Evidence | What logs and artifacts support compliance requests? | Deployment, access, and integration logs with retention rules | “We can pull logs later” without specifying where |
| Handover | What documentation and runbooks ship with the project? | Runbooks, dependency inventory, and environment configuration | Only a final demo with no operational details |
Common Mistakes
Agencies sometimes describe a “stack” as a list of tools without describing how those tools handle health data. A proposal that names a database and a front-end framework but omits retention, access control, and logging cannot answer basic governance questions.
Clients sometimes accept vague integration language like “we’ll connect to the system” without specifying the integration method and error handling. If the API fails, you need to know whether the system retries, queues, or drops events. Without that, the first incident becomes a negotiation.
Another mistake is treating staging as a free-for-all. Staging often contains real or semi-real data, and it still needs the same access restrictions and audit expectations. I’ve seen teams use a staging database with broader permissions than production, which makes later audits awkward.
Finally, both sides can over-focus on the build and under-focus on handover. If the agency does not deliver runbooks and dependency inventories, the client inherits an operational black box. That black box shows up when a minor library update breaks a workflow and no one knows where the change originated.
FAQ
What Is A Client Stack?
A client stack is the set of systems and controls the client already uses, such as identity provider, data storage, content systems, and logging. It defines where data originates, where it can be stored, and who can access it.
What Is A Project Stack?
A project stack is the tooling and runtime used for a specific engagement, including repositories, CI/CD, deployment targets, analytics, and monitoring. It should connect cleanly to the client stack at defined integration points.
How Do I Evaluate Integration Risk?
Ask for a data-flow map, the integration mechanism (API, webhook, ETL, export), and the error-handling behavior. Require logging and retention details so you can trace failures and answer compliance questions.
Do We Need SSO For Every App?
If the app handles staff or patient-related access, SSO integration is usually the safer path because it centralizes authentication and role management. The proposal should describe role mapping and session behavior.
What Should Handover Include?
Handover should include runbooks, environment configuration guidance, dependency inventory, and a list of operational dashboards and alerts. It should also include documentation of metric definitions and event schemas when reporting is part of the scope.
Author's Insight
Agency and client stacks intersect at identity, data movement, and observability. Those three areas determine whether a project can be audited, debugged, and maintained after the engagement ends. When proposals name tools but omit data-flow and access rules, the missing details usually surface during incidents or compliance reviews.
Evidence-based evaluation focuses on artifacts: integration diagrams, retention schedules, role mapping tests, and logging coverage. A practical approach is to request a short “evidence package” checklist during onboarding, then verify it against the delivered documentation at handover.
One small operational detail that often matters: confirm the monitoring tool version and event schema versioning (for example, analytics event schema v3) so changes do not silently break reporting.
Key Takeaways
Map data flows and retention per environment before choosing tools, then align identity and permissions through the client’s SSO approach.
Require a release and rollback plan with pinned dependencies, and demand audit evidence that ties deployments and access to integration events.
Use the comparison checklist to judge proposals by governance and maintainability, not by tool names alone.
