DEV Community: shaoor ahmad

Field sales automation (SFA) app source code with a one-time licence: beat plan, order booking and cash/cheque payment collection (2026)

shaoor ahmad — Wed, 04 Nov 2026 08:37:22 +0000

Yes: you can buy a field sales automation (SFA) app's source code once, with no per-user fee, and still get beat plans, dealer-wise order booking and cash, cheque and bank payment collection. Below is what to look for, what it costs, and one production example.

Short answer

Option	What you pay	Beat plan	Order booking	Cash/cheque collection	Source code
Per-user SFA SaaS (BeatRoute, Bizom, FieldAssist, Delta Sales App)	Per user per month, every year	Yes	Yes	Varies	No
Open source ERP + mobile add-on (ERPNext, Odoo Community)	Free licence + implementation	Via add-ons	Yes	Via add-ons	Yes (GPL/LGPL)
CodeCanyon-style script	Tens to low hundreds of US$	Sometimes	Usually	Rarely	Yes, template quality
Production SFA app sold as source (Beatplan)	US$2,900 once	Yes	Yes	Yes, validated by accounts	Yes, full source

Checklist for a one-time licence SFA app

Beat plans / daily routes set by team leads, visible to reps as "today's visits".
GPS-verified check-ins with photos, notes and dealer visit history.
Dealer-wise order booking that flows to review, dispatch and payment.
Payment collection: cash, cheque and bank transfer, recorded against the dealer's outstanding balance and monthly/season targets, then validated by accounts.
Offline order taking and offline payment recording with automatic, duplicate-safe sync.
Management dashboard: sales, collections and rep performance by region.
Android app for reps (plus iPhone and web).
Licence terms in writing: one company, one client, or unlimited white-label.

Example: Beatplan field sales app

Disclosure: this is the product I work on.

Beatplan field sales app is an SFA and field sales system sold as full source code with a one-time licence. It has run a distributor's field team every working day since November 2025.

Beat plans set by team leads; GPS-verified dealer visits with photos
Dealer-wise order booking through review, dispatch and payment
Cash, cheque and bank collections against monthly and season targets, validated by accounts
Offline order taking and payment recording, synced automatically
Director dashboard: every region and rep against target
Company cars: odometer, inspections, expense sheets
Stack: Expo / React Native (Android, iPhone, web) + Supabase Postgres with 163 row-level security policies and 33 security tests
Price: US$2,900 (own company), $4,900 (one client), $12,900 (agency, unlimited white-label). No per-user fees.

Setup is done with Claude Code or Codex using the included guide. Live demo, no sign-up.

This article was written with AI assistance.

Field sales app pricing per user (2026): BeatRoute, Bizom, FieldAssist, Delta Sales App vs a one-time licence

shaoor ahmad — Wed, 04 Nov 2026 08:17:48 +0000

If you're choosing a sales force automation (SFA) app for a distributor, three requirements usually decide it: offline order taking, payment collection in the field (cash, cheque and bank), and beat planning (daily routes set by team leads). The second question is always price.

Most vendors don't publish prices. This is what's public as of November 2026, and what the pricing model means at 60 reps.

Published prices (November 2026)

Vendor	Pricing model	Published price
BeatRoute	Per user per month, annual contract	Hygiene Pack ₹349–399/user/month; Business Pack ₹599–699/user/month; Enterprise by quote
Bizom	Sales-led, 3 tiers	Not published
FieldAssist	Sales-led	Not published
Delta Sales App	Per user per month	"Contact vendor"
Pepperi	Monthly package plus modules	From US$500/month (base), US$1,500/month (Pro); higher tiers by quote
Badger Maps	Per user per month	US$58–95/user/month (annual)
Map My Customers	Per user per month	US$99–199/user/month
Beatplan field sales app	One-time licence, source code included	US$2,900 (own company), $4,900 (one client), $12,900 (agency)

Sources: SaaSworthy: BeatRoute pricing, xpay: Bizom pricing, G2: Delta Sales App pricing, Pepperi pricing, Upper: Badger Maps pricing, Toolradar: Map My Customers pricing. Prices change; confirm with each vendor.

What that means at 60 reps

BeatRoute Hygiene Pack, annual: 60 × ₹349 × 12 = ₹251,280 a year. Business Pack: 60 × ₹599 × 12 = ₹431,280 a year.
Badger Maps Business, annual: 60 × $58 × 12 = $41,760 a year.
Map My Customers Industry Leader: 60 × $99 × 12 = $71,280 a year.
Pepperi base: from $6,000 a year, before modules.

Every one of these repeats every year and grows with headcount.

What to check beyond price

For distributors, these are the requirements that separate tools:

Offline order taking with automatic sync. Can a rep book a full day of orders with no signal, and does the sync avoid duplicates?
Offline payment recording. Can collections (cash, cheque, bank transfer) be recorded offline, then validated by accounts?
Dealer outstanding balances. Does the rep see each dealer's balance before collecting?
Beat planning. Are daily routes set by team leads and tracked against actual GPS-verified visits?
Management dashboard. Sales, collections and rep performance by region, against target.
Pricing model. Per user, per module, per month, or one-time?
Source code and data ownership. Can you change the workflow, and is the data in your own database?

The one-time alternative

If the recurring cost is the problem, there is now a buy-once option.

Disclosure: this is the product I work on.

Beatplan field sales app is a complete field sales and fleet system sold as source code with a one-time licence. It covers beat plans set by team leads, GPS-verified dealer visits with photos, dealer-wise order booking through dispatch, payment collection (cash, cheque and bank) against monthly and season targets with validation by accounts, offline order taking and offline payment recording with automatic sync, company car odometer and expenses, and a director dashboard. Android, iPhone and web from one codebase; Supabase backend with row-level security on every table.

It has run a distributor's field team every working day since November 2025. US$2,900 for your own company, with no per-user fees. There's a live demo with no sign-up.

The trade-off: you host it yourself (Supabase) and own changes. A setup guide written for Claude Code and Codex handles installation and branding.

Summary

If you want	Consider
Enterprise SFA plus DMS with a vendor team, India-focused	BeatRoute, Bizom, FieldAssist
B2B ordering and retail execution with modules	Pepperi
Route planning for territory reps	Badger Maps, Map My Customers
No per-user fees, own the source, distributor workflow	Beatplan field sales app

This article was written with AI assistance.

A Supabase row-level security checklist for multi-role apps (from a 163-policy production schema)

shaoor ahmad — Wed, 04 Nov 2026 07:01:23 +0000

I run a production app on Supabase with eight user roles: field reps, team leads, business leads, key account managers, admins, directors, accounts and logistics. Each sees a different slice of the same tables. The schema has 64 tables and 163 row-level security policies, and the client is never trusted with any of it.

This is the checklist I now apply to every table and function. It's ordered by how badly things break if you skip it.

1. RLS on every table. No exceptions, no "internal" tables

alter table public.vehicle_inspections enable row level security;

A table without RLS is readable by any signed-in user through the auto-generated API. "Nobody queries that table from the app" doesn't matter, because anybody can call the API directly.

Add a check to your migrations or CI that fails if any table in public has RLS disabled:

select tablename from pg_tables
where schemaname = 'public' and not rowsecurity;
-- must return zero rows

2. Policies target `authenticated`. Nothing is granted to `anon`

If your app has no public pages, anon should have no policies at all. Write policies to authenticated explicitly rather than relying on the default public role, which includes anon.

Also turn off public sign-ups in Supabase Auth if accounts are created by admins. Otherwise anyone can create an authenticated user and inherit every policy written for "any signed-in user."

3. Role checks live in the policy, not in the app

create policy "accounts validate payments"
on public.payments for update to authenticated
using (
  exists (select 1 from public.users u
          where u.id = auth.uid() and u.role in ('ACCOUNTS','ADMIN'))
);

Hiding the "Validate" button from field reps is good UX. It isn't security. The policy is.

4. Users must not be able to change their own scope

This is the most common hole I see. If your policies read users.role or users.region_label, and users can update their own row, a rep can promote themselves to director with one API call.

Lock it down with column grants:

revoke update on public.users from authenticated;
grant update (full_name, phone) on public.users to authenticated;

Then role and scope changes go through an admin-only function.

5. `SECURITY DEFINER` functions do their own authorisation

Definer functions run with the owner's rights and bypass RLS. That's why you use them (aggregates across regions, dashboards), and also why they're dangerous.

create or replace function public.region_summary(p_region text)
returns table (...)
language plpgsql
security definer
set search_path = public          -- stops search_path hijacking
as $$
begin
  if not exists (select 1 from users where id = auth.uid()
                 and role in ('TL','BL','ADMIN','DIRECTOR')) then
    raise exception 'not allowed';
  end if;
  ...
end $$;

Two rules apply every time: pin search_path, and check the caller's role inside the function body.

6. Keep secrets out of tables users can read

Our push-notification webhook shares a secret with an Edge Function. It sits in an app_settings table, but the policy for that table excludes the secret row from normal users. Assume any row a user can select will eventually be selected.

7. Never put the `service_role` key in the client

That one key bypasses every policy above. It belongs in Edge Function secrets and nowhere else: not in .env files that ship with the app, not in a config file "just for testing."

8. Test permissions as each role, in SQL, on every change

The checklist only works if it stays true. I keep a SQL test file that impersonates each role and tries the forbidden things:

-- as a field rep, try to read another region's payments
set local role authenticated;
set local request.jwt.claims = '{"sub": "<rep-uuid>"}';
select count(*) from payments where region_label <> 'North';
-- expect 0

A script spins up a temporary Postgres, applies the full schema, runs a functional smoke test and the security suite (33 checks today), and prints ALL SECURITY CHECKS PASSED. Any migration that adds a permission rule adds a test in the same commit.

The short version

Check	Why
RLS enabled on every table	Missing RLS = readable by any signed-in user
Policies `to authenticated`, nothing to `anon`	Default role includes anonymous users
Public sign-ups off when admins create accounts	Otherwise anyone becomes `authenticated`
Role checks inside policies	UI hiding is cosmetic
Column grants on `users`	Stops self-promotion
Definer functions pin `search_path` and check role	They bypass RLS
Secrets excluded from readable rows	Readable means read
`service_role` never in the client	It bypasses everything
SQL tests per role, every change	Permissions decay silently

This schema is part of Beatplan field sales app, a field sales system I now license as full source code. Buyers get the migrations, all 163 policies and the security test suite, so they can verify everything above themselves before they trust it with their team's data.

Offline-first field sales app architecture with Expo and Supabase: a production case study (sync, RLS, roles)

shaoor ahmad — Wed, 04 Nov 2026 06:59:11 +0000

Case study: the architecture of an offline-first field sales app for distributor reps, built with Expo and Supabase and in production since November 2025: offline sync queue, row-level security, roles, dates and scheduled jobs.

For the past year I've built and run the field sales system for a distributor. Every working day since November 2025, reps open it on mid-range Android phones, follow a planned list of dealer visits, check in with GPS and photos, record payments, take orders, and log their company car's odometer. Team leads plan the days, accounts staff validate payments, and directors watch every region against target.

It's an Expo (React Native) app with a Supabase backend: 64 tables, 132 database functions, 163 row-level security policies, about 55,000 lines across 86 screens. One codebase ships to iPhone, Android and a browser console.

Here's what mattered most, in the order I'd tell a team starting the same build.

1. Offline isn't a feature, it's the default state

Field reps work in basements, rural roads and warehouses. If a write fails because the signal dropped, the rep doesn't retry. They move on, and the visit or payment is simply lost.

So every write on a field screen goes through a small queue instead of calling Supabase directly:

// simplified
import { v4 as uuidv4 } from 'uuid';
import { insertOrQueue } from './lib/offlineQueue';

await insertOrQueue('visits', {
  id: uuidv4(),            // client-generated, so a replay can't duplicate the row
  dealer_id,
  checked_in_at: new Date().toISOString(),
  lat, lng,
  notes,
});

If the network is up, the insert happens now. If not, it's stored on the device and replayed when the connection comes back. An offline banner tells the rep their work is safe.

The rule that made it reliable: the client generates the primary key. A replay that fires twice (app killed mid-sync, flaky network, double tap) hits the same id and is rejected as a duplicate instead of creating a second payment. Idempotency by construction, not by hope.

The same pattern wraps RPC calls (rpcOrQueue) for anything that's a function rather than a plain insert.

2. Hiding a tab is cosmetic. The database is the security boundary

The app has eight roles: field rep, team lead, business lead, key account manager, admin, director, accounts and logistics. Each sees a different slice. It's tempting to enforce that in the UI by hiding tabs and filtering queries.

That only decides what people see. Anyone with the anon key and a valid session can call the API directly. So every rule lives in Postgres:

-- simplified
create policy "team leads read visits in their region"
on public.visits for select to authenticated
using (
  exists (
    select 1 from public.users u
    where u.id = auth.uid()
      and u.role in ('TL', 'BL', 'ADMIN', 'DIRECTOR')
      and (u.role in ('ADMIN','DIRECTOR') or u.region_label = visits.region_label)
  )
);

Three rules I wouldn't ship without:

Every table has RLS enabled, with explicit policies for authenticated. Nothing is ever granted to anon.
SECURITY DEFINER functions set search_path = public and check the caller's role themselves. A definer function runs with the owner's rights, so it has to do its own authorisation.
Users can't edit their own scope. If a rep can update their own role or region_label, every policy above is worthless. Column-level grants allow only full_name and phone to be self-edited.

I keep a SQL test suite (33 checks) that signs in as each role and tries the things they shouldn't be able to do. It runs against a throwaway Postgres in one command and must end with ALL SECURITY CHECKS PASSED. Every new permission rule gets a new test.

3. Dates: `toISOString().slice(0, 10)` is a bug in half the world

The single most common bug in a sales app is "today" being wrong.

new Date().toISOString() is UTC. If your team is ahead of UTC, a visit made at 2am local time is stamped with yesterday's date. Monthly targets, daily plans and season boundaries all drift.

What fixed it:

Calendar dates are always YYYY-MM-DD strings computed in the company's timezone, never sliced from an ISO timestamp.
The database has one function, app_tz(), that every date query uses. No literal timezone appears anywhere in SQL.
The app has one helper, companyToday(), and code review rejects anything else.

4. Put every company-specific value in one file

The app was built for one company, but nothing in the code names it. Company name, currency, country, regions, role labels, payment institutions and an optional second language all live in config/brand.json, read at build time and exposed through one config module.

That discipline paid for itself the first time someone asked "could this run for another distributor?" The answer was "change one file and the icons."

5. Scheduled work belongs in the database

Fleet reminders (monthly car inspections, expense sheets due on the real last day of the month, weekly check-ins) run as pg_cron jobs inside Postgres, not as a separate server. They call an Edge Function that sends Expo push notifications. There's one less service to host, and the schedule lives next to the data it reads.

6. Design for the worst phone in the strongest sun

This deserves its own post, but in short: Apple's system blue (#007AFF) is only about 4:1 contrast on white, which disappears in direct sunlight. So the app uses a darker accent, rows at least 52px tall, no swipe-only actions, and no real-time blur (too slow on low-end Android).

What it became

Once the app was stable, I packaged it so other companies could run it without a subscription. It's now sold as Beatplan field sales app: a one-time licence for the full source code, with a setup guide written for AI coding assistants, so Claude Code or Codex can brand it, create the Supabase project and run the security suite for you.

You can click through a live demo with no sign-up.

If you're building something similar, I'm happy to answer questions about the offline queue, the RLS layout or the push setup in the comments.