−65%
publication time
Pray The Bible admin panel
An internal tool with AI inside it, used by non-technical staff. Training time is the number that matters here: two weeks to two days.
Read the case studyWeb Apps & Admin Panels
Web Apps & Admin Panels
The screen your team logs into every morning.
Admin panels, dashboards, customer portals and the browser version of your product, built on the same stack as your app, by the same team, so it is one product and not two vendors blaming each other.
Your code, your cloud accounts, your data. On final payment it is all yours.
52+
Apps and products delivered
7+
Years
Top Rated
Upwork agency
100%
Job Success
54
Client reviews
Products we have built the web side of
Panels and portals already in use
Every real product needs more than the app. Somebody has to approve content, manage users, see the numbers, handle a refund and change what is on the home screen, without calling a developer. That is the admin panel. Then your business customers want the same product in a browser, and your team wants a dashboard that is not a spreadsheet emailed around on Monday. We build all of it, on the same stack as your app, so it stays one product with one team behind it.
Who you’ll actually work with
Anand Yadav
Founder, SightInfusion InfotechUpwork Top Rated100% Job Success54 reviews52+ apps and products delivered
Admin panels are where I have watched the most money get wasted, and it is almost never a technical failure. It is that the panel was designed for the developer who built it and not for the person in operations who has to open it forty times a day.
So I ask a different first question. Not ‘what should it do’. ‘Who opens this, and what are they doing in the ninety seconds before they open it’. That question changes the whole design, and it is the reason our panels get used.
I am on every project.
Four things, and they are not the same thing
What we build
| Type | What it is | Who opens it | Typical proof |
|---|---|---|---|
| Admin panel | The control room for your product. Approve, edit, publish, manage users, set permissions, change what customers see | Your own team, daily | PTB admin, publication time down 65% |
| Dashboard and reporting | The numbers the business actually runs on, in one place, updating live | Managers and owners, weekly | PM Fund Manager, reporting from 2 to 3 days to minutes |
| Customer / partner portal | Your clients log in and see their own orders, data, documents and invoices | Your customers, unpredictably | Tata Power SolaRoof, 99% asset tracking accuracy |
| Web version of your mobile app | The same product in a browser, for people who work at a desk | Whoever prefers a keyboard | Shares the codebase and the backend with the app |
The question nobody asks until month three
Will your staff actually use it?
Internal tools do not usually fail because the code is wrong. They fail because the people who were supposed to use it went back to the spreadsheet.
Homegrown internal tools rarely fail because the code doesn't work. They fail because the builder skipped the product loop. Iterating without outside signal isn't iterating. It's decorating.
What we do about it, on every panel we build:
| What we do | What that means |
|---|---|
| We watch someone do the job first | Before design. The real job, with the real spreadsheet, at their desk or on a call |
| The person who will use it reviews the design | Not only the person paying for it. These are usually different people, and that is the whole problem |
| The 90-second rule | The three things that person does most must each take under 90 seconds and no more than two clicks from login |
| We measure training time | And we publish it. On the Pray The Bible panel, training went from two weeks to two days |
| A 30-minute recorded walkthrough | Shipped with the panel, made for the staff, not for the buyer |
Real numbers from panels we have built: publication time −65% · training 2 weeks to 2 days (PTB admin) · admin time −60%, errors −95% (PM Fund Manager) · workflow friction −70%, scaled 50 to 500+ field workers (Companion app, private deployment, client not named).
When you should not hire us
Build it or buy Retool? An honest answer.
Every buyer in this market asks this, and most agency pages pretend the question does not exist.
Buy the tool (Retool, Appsmith, Budibase, Airtable) when
- The tool is for a small internal team and the workflow is standard.
- Nobody outside your company will ever log in.
- You can live inside the tool's limits, and you are honest that you do not yet know where they are.
- You would rather pay monthly than once.
Build it custom when
- Customers log in. A portal your clients use is your product, and it will need your brand, your terms, and accessibility. That is where per-seat tools get awkward and expensive.
- It has to sit on top of the app we are already building. Same data model, same auth, same team.
- The workflow is your actual advantage. If your process is what makes you money, renting somebody else's shape for it is a bad trade.
- Per-seat cost has stopped making sense. Published prices, checked August 2026: Retool Business $50 per builder and $15 per internal user per month. Appsmith Business $15 per user per month, Enterprise around $25 with a 100-user minimum. Budibase around $50 per creator and around $5 per end user per month.
The honest part: there is no reliable published crossover point where custom becomes cheaper. Anyone who gives you a precise number of users where custom “wins” has made it up. What is true is that per-seat pricing scales with your headcount and a custom build does not, so the question is not “which is cheaper today” but “which curve do I want to be on in three years”.
And if the answer is buy the tool, we will say so on the first call, and point you at Low-Code / No-Code Builds if you want help setting it up properly. Small job, right tool.
Who keeps this running
The year-two question
The most repeated fear in this market, in the buyer’s own words:
Do you also love to maintain the tools you build? That's at least half the reason you buy instead of build.
A custom panel that nobody maintains stops being an asset fairly quickly. So we answer it before you sign, not after:
| Option | What it means |
|---|---|
| You maintain it | Full handover, documented, your repository and your accounts. We write the runbook for your developer. Normal, and not penalised. |
| We maintain it | Monthly plan. See Mobile App Maintenance & Optimization. |
| Nobody maintains it, on purpose | Some internal tools genuinely have a two-year life. If that is yours, say so and we will build it cheaper and simpler on purpose. |
The third row is real advice. Building a ten-year system for a two-year problem is the most common way money gets wasted in this category.
What the law says, and what it does not
Accessibility: which of these is actually covered by law
There is a lot of confident nonsense about this, so here is the distinction that matters, with sources.
| Your web thing | European Accessibility Act |
|---|---|
| A customer-facing portal or web app (your clients, the public, e-commerce, banking services) | In scope. The EAA has applied since 28 June 2025 |
| A purely internal, employee-only admin panel | Generally out of scope. The EAA covers products and services placed on the market, not employee-facing systems |
| A mixed system (one CMS serving both an internal intranet and public content) | The public-facing part is in scope, so in practice the system is treated as in scope |
Microenterprise exemption: fewer than 10 employees and annual turnover or balance sheet total of €2 million or less, and only for service providers (CCPC, Irish regulator).
Two honest caveats. Some member states (France and Italy are cited) extend accessibility duties to internal platforms through national law layered on top of the EAA. We found this in a single secondary source and have not verified it against national statute, so treat it as a question for your lawyer rather than a fact from us. And in the United States, the 2026 ADA Title II web rule applies to state and local government only. Compliance dates were extended to 26 April 2027 for large jurisdictions and 26 April 2028 for small ones (Federal Register). There is no equivalent binding private-sector rule.
What we do: we build to WCAG on anything a customer logs into, whether or not the law reaches you, because the same work also fixes keyboard use, contrast and screen size, which your staff notice long before a regulator does.
Checked 12 August 2026.
Industries
Industries we serve
| Industry | What we have built | Proof |
|---|---|---|
| CRM, HR and internal business tools | Fund management, CRM, workflow tools | PM Fund Manager · FMSoft CRM |
| Fintech and banking | Crypto and wallet admin, lending back office | Cryptendo admin · Hindustan Loan |
| Energy and utilities | Field operations, asset tracking, enterprise portals | Tata Power SolaRoof |
| Legal-tech | Case and document management | DigitsLaw · ActivePass |
| Retail and POS | Inventory, invoicing, merchant back office | Vencru POS |
| Media and community | Publishing and moderation panels | PTB admin · Azad Sandesh |
| Logistics and field operations | Offline-capable field tools | Companion app, private deployment, client not named |
| Healthcare and wellness | Open. No case study yet | No claim made |
Beyond the marketing site
Most web work is an app wearing a website
Logins, dashboards, roles, billing, exports. Once a page holds state it has stopped being a page. We build the second kind, and the choices below follow from that.
Process
How we work
130 min
First call
What is it, who opens it, and honestly, should you buy a tool instead.
22 to 4 hours
Watch the job being done
With the person who does it now, and their spreadsheet.
33 to 5 days
Screen map and roles
Every screen, every role, every permission, on one page.
41 week
Design the three most-used screens
Reviewed by the person who will use them, not only by the buyer.
52 weeks each
Build in two-week blocks
Something you can log into at the end of every block.
63 to 5 days
Real-data test
Your actual data volumes, not ten sample rows.
71 day
Staff walkthrough and recording
The 30-minute video that ships with the panel.
82 to 3 days
Handover and runbook
Accounts, keys, deployment, and how to add a user.
What clients say
Great experience working together. Communication was clear and consistent, and the work delivered aligned well with the requirements provided. Tasks were handled thoughtfully, with good attention to detail and a willingness to ask questions when clarification was needed.
This was a long and complicated project. However, Anand executed it flawlessly. He was patient with the requirements, was a fast learner in situations where he encountered something new and was a great and prompt communicator.
I had the pleasure of hiring Anand to work on our mobile app. His attention to detail was evident in every aspect of the project, ensuring a smooth and polished user experience. Anand has a keen eye for design, transforming designs into visually appealing and functional interfaces.
Tech we use
Web
ReactNext.jsTypeScriptTailwind
Backend
Node / TypeScriptPostgreSQLFirebaseSupabase
Auth and permissions
Role-based access, SSO where you need it, audit logging
Reporting
Live dashboards, scheduled exports, CSV and PDF
Mobile, when it shares the codebase
FlutterReact Native
Delivery
GitHub, CI/CD, staging environment you can log into, error monitoring
Same stack, same backend, same team as your mobile app. That is the whole reason to have us do both.
Questions buyers actually ask
What is the difference between an admin panel and a dashboard?
A panel is for doing: approve, edit, publish, refund. A dashboard is for seeing. Most clients ask for a dashboard and need a panel. What we build.
Why not just use Retool or Airtable?
Sometimes you should, and we will tell you when. Full answer in build it or buy Retool, including current per-seat prices.
At how many users does a custom build become cheaper than Retool?
There is no honest published answer, and anyone who gives you a precise number invented it. What is true is that per-seat pricing grows with headcount and a custom build does not. Build it or buy Retool.
Will my team actually use it?
That is the real risk, and it is the reason we watch the job being done before we design anything, and put the daily user in the design review. Training on our last panel went from two weeks to two days. Will your staff actually use it.
Do I own it?
Yes. Code, designs, cloud accounts, data export, on final payment.
Who maintains it in year two?
Your choice, decided before you sign: you, us, or deliberately nobody if the tool has a short life. The year-two question.
Does accessibility law apply to my admin panel?
If only your employees use it, generally no. If your customers log in, yes. The European Accessibility Act has applied since 28 June 2025. Full detail and the microenterprise exemption in accessibility.
Can you build the web version of my existing mobile app?
Yes, and if we built the app it is roughly two weeks because it shares the backend and the data model.
Can it connect to our CRM / accounting / ERP?
Yes. That work lives on Backend, API & Integrations, and we scope it together with this.
Can you add AI so people can just ask the data a question?
We can. We will also tell you we could find no independent adoption data for that feature. Every source was a vendor. Treat it as a bet.
What if we already have a panel and it is a mess?
Start with a paid interface audit rather than a rebuild. Often the fix is three screens, not a new system.
How do you handle our real data volumes?
We test on your actual volumes before handover, not on sample rows. It is step 6 of how we work and it is where most panels quietly fail.
Do you do marketing websites?
No. This is the web a product needs: panels, dashboards, portals, and browser versions of apps.
Can our own developer take it over?
Yes, and we write the runbook for them as part of handover.
Have something in mind
Tell us the problem. We bring the engineering.
A short call, an honest answer on whether we are the right team, and a scope you can hold us to.
Start a project