Software built around the identity and data it depends on.
We build and modernize web apps, mobile apps and integrations, and we start with the questions that usually get asked last. Who signs in. Which token each service holds. Which system owns each piece of data.
Application services covers building new software and fixing old software, including web applications, iOS and Android apps, APIs and integrations, and the modernization of legacy systems.
Cohash engineers design, build and maintain these applications with sign-in and API authorization designed up front, using Auth0, Okta or Entra ID, and connect them to Salesforce, Dynamics 365 and data platforms such as Snowflake.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Application Services, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · where you end up
incident board · application services3 open
openCustomers use a portal that still stores its own passwords.
recurringAn app runs on a framework version that no longer gets security patches.
blockedData is re-keyed by hand between the CRM, ERP and a custom system every week.
exposure
Web developmentMobile developmentAPI integrationLegacy modernizationPlatform deadline upgrades
ready to hand over
The portal runs on a supported runtime and holds no passwords.
Orders reach the ERP without re-keying, and the integration user can only touch the…
chapter 01 · where it hurts
Why teams reach out
Customers use a portal that still stores its own passwords.
An app runs on a framework version that no longer gets security patches.
Data is re-keyed by hand between the CRM, ERP and a custom system every week.
chapter 02 · what we change
How we solve it
Web development
Mobile development
API integration
Legacy modernization
Platform deadline upgrades
chapter 03 · where you end up
What changes
The portal runs on a supported runtime and holds no passwords.
Orders reach the ERP without re-keying, and the integration user can only touch the objects it needs.
what we do
Where we spend the hours
5 areas of work, each one done by an engineer who has run it in production.
We build customer portals, internal tools and public sites to WCAG 2.2 AA, and we measure them on Core Web Vitals. Sign-in goes to an identity platform instead of a password table.
Native Swift and Kotlin apps, or React Native and Flutter where one codebase fits, kept current with Apple and Google store requirements every year.
We build REST and event-driven integrations between CRM, ERP, data platforms and custom apps, and every one of them has its own OAuth client, scopes and monitoring.
Old .NET Framework, Java and mainframe applications modernized in slices, with the old and new systems running in parallel until their outputs match.
Upgrades driven by vendor dates. .NET 8 support ends on 10 November 2026, App Store uploads need Xcode 26, and Google Play updates must target Android 16.
capability 01 / 05in production
Web development
We build customer portals, internal tools and public sites to WCAG 2.2 AA, and we measure them on Core Web Vitals. Sign-in goes to an identity platform instead of a password table.
We build REST and event-driven integrations between CRM, ERP, data platforms and custom apps, and every one of them has its own OAuth client, scopes and monitoring.
Upgrades driven by vendor dates. .NET 8 support ends on 10 November 2026, App Store uploads need Xcode 26, and Google Play updates must target Android 16.
We pieced these together from Application Services situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Customer portal on .NET 8 with its own password table
composite · not a client story
Beforethe situation
The customer portal is on ASP.NET Core 8, with password hashes and email-based resets sitting in ASP.NET Core Identity tables. Support for .NET 8 ends on 10 November 2026. Security wants the passwords out of the application.
What we dothe work
Upgrade to .NET 10 and its dependencies on a branch first. Meanwhile, stand up Auth0, Okta or Entra External ID, migrate users either by bulk hash import or on first sign-in, and switch the portal to OpenID Connect. Once the last active user has moved, drop the password tables.
Afterwhere you end up
The portal runs on a supported runtime and holds no passwords. Resets, MFA and lockout have moved to the identity platform, where the security team can actually see them and tune them.
case file 02
Orders re-keyed every morning between a custom app and Dynamics 365
composite · not a client story
Beforethe situation
Sales reps put orders into a custom web app, and every morning an operations clerk re-keys them into Dynamics 365. The same app talks to Salesforce through one integration user that holds System Administrator.
What we dothe work
Map which system owns each order and customer field. Build an integration service with its own OAuth client per target, scoped to the objects it writes, and use idempotency keys so retries never create a second order. Retire the manual step after a parallel week reconciles.
Afterwhere you end up
Orders reach the ERP without re-keying, and the integration user can only touch the objects it needs. A failed sync raises an alert instead of waiting for someone to notice.
Where custom applications sit between users, identity and your core systems
Web and mobile front ends sign users in through an identity platform and call APIs with scoped tokens. The API layer connects to CRM, ERP and data platforms, while legacy systems are wrapped and replaced in slices.
Where custom applications sit between users, identity and your core systemsWeb and mobile front ends sign users in through an identity platform and call APIs with scoped tokens. The API layer connects to CRM, ERP and data platforms, while legacy systems are wrapped and replaced in slices.01 · USERS02 · IDENTITY03 · APPLICATION LAYER04 · CORE SYSTEMSOIDC sign-inOAuth with PKCEaccess tokenOAuth clientOAuth clienteventsstrangler routingWeb applicationsportals · internal toolsMobile appsiOS · AndroidIdentity platformAuth0 · Okta · EntraIDAPIs and servicesREST · eventsLegacy application.NET Framework · Java ·mainframeSfCRMSalesforceD365ERPDynamics 365Data platformSnowflake
Put these to anyone bidding on your Application Services work. The ones who've done it answer differently from the ones who've read about it.
Q1
When the project ends, who owns the repositories, pipelines and signing keys?
If the code sits in the partner's GitHub organization, or the store signing key is on a consultant's laptop, switching vendors gets painful. Put ownership in the contract and set it up that way on day one.
Q2
How will users sign in? Will the app store any passwords?
Keep passwords in your app and you also own resets, lockout, MFA and breach response. Hand sign-in to an identity platform over OIDC, and that work moves to a system built to do it.
Q3
Which vendor deadlines in the next 18 months hit this application?
.NET 8 support ends on 10 November 2026. App Store uploads need Xcode 26, and Google Play updates must target Android 16. Expect a partner to list dates like these before giving a quote.
Q4
How will you test what happens when an integration fails?
Integrations break in production on timeouts, duplicate messages and expired tokens. Ask to see the failure test cases for each one before build starts.
Q5
What does first-year maintenance cost after launch?
SDK, runtime and store policy changes arrive every year and aren't optional. A quote for the build alone pushes that cost into next year's budget without saying so.
01Do you build new applications or extend existing ones?
Both. A lot of our work is extending or upgrading software that already runs the business, because that is where the deadlines and the risk usually sit.
02Which technology stack do you use?
Yours, if you have standards. For new builds we recommend a stack based on what your team can maintain after launch, which often matters more than any framework benchmark.
03How do you estimate an application project?
From a short discovery that fixes scope, integrations and non-functional needs such as accessibility, performance and compliance. Integrations and data migration are usually the biggest cost drivers, more than screens.
04Do you also support applications after launch?
Yes. We can maintain the application, handle platform upgrades and store submissions, or hand over to your team with runbooks.
05Can your engineers work alongside our in-house developers?
Yes. Many projects mix our engineers with yours in one backlog, using your repositories, code review rules and pipelines. That keeps the knowledge with your team when we step back.
related
Often paired with
Projects on Application Services usually end up touching one of these, so they're worth a look.