Aashwasan: delivered work

What problem does Aashwasan solve?

Chat messages are not reliable proof of what was promised. A single missed message can lead to disputes over scope, payment or deadlines. Aashwasan is a comprehensive ecosystem designed to simplify the relationship between service providers and clients.

Without a formal system, you might accept a job over WhatsApp, do the work. Then face delays or lower pay because the original message was unclear or deleted. Aashwasan acts like a shared notebook where every agreement is recorded and updated in a clear sequence. This reduces confusion and builds trust, especially when working with new clients or freelancers.

For example, a graphic designer in Bangalore can log a contract for a logo redesign, set milestones, and mark completion with proof. The client sees each update in real time, just like tracking a food delivery. This replaces the need to scroll through long chat histories or dig up old emails.

What features does a contract app need?

What is in the core workflow?

Aashwasan offers contract creation, real-time order tracking, secure communication, integrated PDF handling, and push notifications. You can create a contract, track its status in real time, and communicate securely with the other party. The app has integrated PDF handling, so you can view and share documents without leaving the app. Push notifications keep both sides informed of updates. It does not include payment processing, as that is not stated in the evidence.

The app focuses on trust through transparency, not automation of payouts. For a similar flow, you need a clear state model for contracts and rules for who can change what.

How Legease handles legal agreements shows a different approach to agreement structure.

Why Firebase and Flutter?

Aashwasan uses Firebase as its backend and Flutter for the frontend to deliver fast, reliable cross-platform access with offline support. A managed backend like Firebase handles user authentication, data storage, and real-time sync without needing custom server code. This lets you focus on the app’s features, not infrastructure. Firebase cuts setup time and scales automatically, which suits early-stage apps with uncertain traffic.

Flutter allows one codebase to run on iOS, Android, web, and desktop. This reduces development cost and ensures a consistent experience across devices. For gig or contract apps where workers use different devices, cross-platform reach matters. Flutter also supports offline-first features, and Firebase’s Cloud Firestore backs this with built-in offline data sync for Apple, Android, and web clients.

For example, a delivery partner can sign a contract on their phone offline, and it syncs securely once online. This is critical in areas with poor connectivity. While Firebase speeds up delivery, it has limits in complex queries and access control, which we cover next.

Compare Firebase or a custom backend? to see which fits your scale and control needs.

What are Firebase's technical limits?

When you hit a Firestore limit, the operation fails and your app must handle the error. For example, if you exceed the maximum number of concurrent exports, new export requests may be affected. This can delay data backups or migrations. Each limit acts as a hard cap, so your design must stay within these bounds.

These limits affect scalability by forcing early architectural choices. If your app grows beyond 200 single-field TTL configurations, you must enable billing. Without billing, you cannot scale automated data expiry. Security rules also have hard constraints: you can nest match statements up to 10 levels deep. Paths within them can have at most 100 segments. Exceeding any limit breaks the rule set.

You can make 10 exists(), get(), or getAfter() calls per request in single-document or query requests. Multi-document reads, transactions, and batched writes allow up to 20 such calls. This shapes how you validate access across documents. Function call depth is capped at 20, and nested match statements can use up to 20 path capture variables. These rules ensure performance but limit complexity.

For high-scale apps, these numbers mean you must simplify logic early. Deep nesting or complex path patterns will hit limits. You must plan for 50 maximum concurrent export and import operations, which affects how you schedule data jobs. All limits are fixed, so scalability depends on working within them, not around them.

How are messages and agreements protected?

A user cannot edit a message after sending it in Aashwasan. Each message is protected using a nonce and a signed response. A nonce is a unique, unpredictable value added to a message before it is sent. This ensures that no one can reuse or alter the message later. The system includes the nonce in a digest of the message content. If even one character changes, the fingerprint no longer matches, and the system flags the message as tampered. The Play Integrity API then provides a signed response token. This signed token is stored with the message, making agreements tamper-evident. As a result, both parties have verifiable proof of what was sent and when.

For example, when a gig worker sends an acceptance message. The app can compute a SHA256 digest of the message text and a fresh nonce. The unique value (nonce) must be included in the message and part of the hash to protect against tampering and replay attacks. Once stored, the message is immutable.

To apply similar protection in your app, you must generate a new nonce for every request and validate the signed response on your backend.

How to secure user identity in Flutter

Can you build a two-sided marketplace like this?

Yes, you can build a two-sided marketplace like Aashwasan, but only if you plan for network effects, trust, and liquidity from day one. A two-sided marketplace connects buyers and sellers, creating value by enabling discovery, transactions, and interactions between them. Without both sides active, the platform fails to deliver value.

What makes a two-sided marketplace work is network effects: each new buyer increases value for sellers, and each new seller attracts more buyers. This cycle drives growth, but it starts weak. Most platforms struggle with the "chicken-or-egg" problem, you need sellers to attract buyers, but buyers to attract sellers.

Liquidity is the key metric: it measures how likely a buyer is to find what they want. A seller is to make a sale. Low liquidity kills marketplaces early. You can improve it by starting with a narrow niche, pre-loading inventory, or using manual matching at first.

Starting with low trust? Build in verification, clear rules, and communication tools. Aashwasan uses signed agreements and message logs to create accountability. For your app, consider verified profiles, in-app messaging, and feedback systems. These features help users feel safe before transacting.

However, Aashwasan itself is not a live two-sided marketplace with real users. It is a proof of concept for contract management in gig workflows. Building a real marketplace would need user acquisition, payment handling, dispute resolution, and ongoing moderation, none of which are part of Aashwasan’s current scope.

Hire a developer for a marketplace app if you want to validate your model and design for liquidity and trust.

Is Aashwasan live with real users?

Yes, Aashwasan is available on iOS, Android, Web, and Desktop platforms. It runs on iOS, Android, web and desktop platforms, giving users access across devices. However, the number of active users or clients is not published. You can try the live version through the official project page. This cross-platform availability shows that the core system is stable and designed for real-world conditions.

When this model does not work

Do not use Firebase if your app will grow beyond 1,000 single-field TTL configurations. Which is the limit when billing is enabled for your Google Cloud project. Without billing, the limit is 200 configurations for your Google Cloud project. These rules affect how you automate data expiry at scale.

Avoid this contract app model if you are building a two-sided marketplace. Such platforms rely on network effects: more sellers must attract more buyers, and more buyers must attract more sellers. Aashwasan does not solve for this growth loop.

Also skip this design if you need full data portability or regulatory control over where data lives. Firebase imposes constraints on export formats and regional storage choices.

If your business depends on deep integrations with legacy systems or on-premise databases, a custom backend may be better than a managed service.

Questions people ask