Accounts and access
Separate proving who a user is from deciding what that user may do. Define ownership, roles, session handling and permission checks at the API boundary; hiding a button in the client is not an access rule.
Backend and API development with .NET.
A mobile app and an admin panel often work with the same accounts, records and business rules. FlowApps LAB develops .NET and ASP.NET Core backends that connect those clients to relational data and other systems. Start with the operations people need to complete, then define the API around their permissions, inputs and expected results.
Define what the server is responsible for
Business rules and validation
Keep shared rules on the server so mobile and admin clients cannot produce conflicting outcomes. Specify required fields, allowed state changes, duplicate requests and how a rejected operation is explained to the client.
Relational data and integrations
Map records and relationships before choosing endpoints. PostgreSQL or SQL Server work can include schema design, queries and migrations. For external systems, clarify data ownership, credentials, failure handling and whether a request can safely be retried.
Illustrative workflow: app → API → data
This fictional work-request flow explains the boundaries; it is not a client case study or a description of VitaFlow.
App or admin client
A signed-in user submits a work request with a record identifier and the requested action. The client presents validation feedback and does not decide another user's permissions.
API boundary
The API checks identity, record access and the allowed state transition. It rejects invalid input or applies the business operation, returning a documented result that either client can understand.
Data and response
The data layer saves the change with the required relationships and transaction boundaries. The API returns the saved state; an integration failure needs a defined recovery path rather than a misleading success response.
Agree on the contract and release path
Document request and response shapes, error cases, pagination and compatibility expectations. Test both successful and rejected operations, including integration failures. Before release, agree on environment configuration, secret handling, database migrations, logs, backup responsibilities and rollback steps. Hosting access and ownership affect the work; production readiness is part of scoping, not a promise based on endpoint count.
A practical API scoping checklist
Bring examples of real operations and current constraints. These inputs help distinguish a small integration from a backend that owns a complete workflow.
- Which clients use the API, and which roles may read or change each record?
- What data already exists, where is it stored, and will records need migration or cleanup?
- Which external systems are involved, and are documentation, test accounts and access available?
- What must happen on duplicates, permission failures, partial updates or an unavailable dependency?
- Who owns hosting, release approval and ongoing operation, and what observable results define acceptance?