Internal tools design agency • Prototype-first • You own the code
Internal tools and business portals, designed before they're built
Prototype-first portal design for ops teams and service businesses. We decide what to build, then ship it in Next.js/React. Not another Retool-looking admin.
Build custom when the portal sits at the center of how you sell or operate, when per-seat costs or workflow mismatch make low-code a worse deal than it first looks, or when customers interact with the UI directly. Retool fits fast CRUD for small internal teams who don't need polish. SaaS fits when a standard workflow is genuinely good enough and nobody's building workarounds. The real question isn't which is cheapest, it's whether the tool is overhead or product. Cloud Accountant Staffing's candidate portal is how employers find talent and candidates get placed. That's why we designed and shipped it in Next.js, not Retool, not Bubble. We prototype the portal first so stakeholders can click through it before any engineer commits to a sprint, then we ship production code the client owns.
The problem isn't "we need a dashboard"
Most internal tool problems don't start with a feature list. They start with a spreadsheet that's become load-bearing.
Someone built it in 2021 to track something small. Now ops runs the business from it, six people have edit access, nobody knows which version is current, and the actual problem is that there's no real system. Just a spreadsheet pretending to be one.
That's stage one. Stage two is the SaaS that almost fits. You're paying $50-200 per seat for a tool that handles 20% of your actual workflow while your team builds workarounds for the other 80%. The vendor roadmap doesn't match your process and it never will, because your process is specific to your business and theirs is built for everyone.
Stage three is Retool. It's the right call for a lot of teams. Fast to build, real database connections, solid for internal CRUD. But if your ops team lives in it for eight hours a day, they notice when the UX is rough. And it often is.
Then there's a fourth category that's different from all of these: the client-facing portal that is the business. Hiring platforms, vendor directories, client delivery portals. These aren't internal tools. They're the product. Customers form an impression of your company based on what they see inside it, and that impression is hard to recover from.
When custom beats SaaS and low-code
The honest version of this comparison:
| SaaS | Retool / low-code | Custom portal | |
|---|---|---|---|
| Best when | Standard workflow, no dev resources, fast setup | Internal CRUD, small team, needs real DB fast | Customer-facing, complex roles, the workflow is your differentiator |
| Weak when | Your workflow deviates from their assumptions | Eight-hour daily use, needs polish, customer-visible | Budget is tight and the workflow is genuinely generic |
| Typical cost shape | Per-seat monthly that compounds as you grow | Build time plus ongoing platform cost | Fixed project cost, then you own the code |
A few specific triggers that push toward custom:
Seat cost is compounding. A 30-person ops team at $80/seat is $2,400/month. That's $28,800/year for a tool that doesn't quite fit. Custom pays back faster than most people expect.
The workflow is genuinely multi-role. Retool handles single-role admin panels well. When you've got employers, candidates, and admins all needing different views and permissions, the complexity of low-code starts to exceed the complexity of building it properly.
Customers see it. Anything client-facing should reflect your brand and your workflow, not the constraints of a third-party builder with its own design language.
You need to own the IP. If the tool becomes operationally critical, you probably don't want it locked to a platform you pay rent on forever.
Stay on Retool if...
Your team is small, the use case is internal-only, speed to first version matters more than UX quality, and you're not planning to scale the user base. Retool is good at what it does. We'll tell you when it's the right fit.
How we build portals (prototype-first to production)
The most expensive mistake in portal builds is skipping straight to development. You end up with a technically functional tool that doesn't match how people actually work, and you find that out three months into the build when it's expensive to change.
We start with the real workflow, not a feature list. That means understanding who uses the portal, what decisions they're making inside it, what they're doing before they open it, and what they do after. It almost always surfaces requirements that weren't in the brief and removes requirements that were.
Then we build an interactive prototype. Not wireframes, not a slide deck. Something stakeholders can click through on their phone before any engineer touches a sprint. That's where real alignment happens. Assumptions surface. Every "oh, we also need..." gets caught before it costs real money to change.
We ship in Next.js, React, and Tailwind. That stack is fast to build, maintainable, and what good engineers know. Code you can hand to any competent dev team later without a platform migration. We don't use Framer or Webflow for portals. Those tools are right for marketing sites. They're wrong for authenticated, multi-role apps with real data behind them.
For clients using AI coding tools to extend the portal after handoff, we can deliver a design system with component documentation and AI-ready prompts that keep future code consistent with the original design. We've written about what that looks like in the AI-ready design systems series.
What this looks like in practice
Three builds that show the range of what this work actually looks like.
Cloud Accountant Staffing needed a self-serve talent portal where accounting employers could browse candidates and candidates could manage their own profiles, without a recruiter in the middle of every interaction. The workflow was specific, multi-role, and entirely client-facing. Within six months of launch, the portal had 1,350+ employer signups and facilitated 120+ interviews. That kind of result doesn't happen with a generic tool.
MVP Development
6 weeks
Recruitment & Staffing
Candidate Portal: Transforming Recruitment with a UX-First Platform
Cloud Accountant Staffing
A recruitment company needed to differentiate from traditional staffing agencies by giving employers direct access to browse, filter, and interview pre-vetted accounting candidates through a sophisticated self-service portal.
User Adoption
1,350+ signups in 6 months
Strong market validation from employers seeking accounting talent
Platform Engagement
30,500+ page views
Average of 23 pages per visitor showing deep exploration
Interview Conversion
120+ booked interviews
9.2% signup-to-interview rate demonstrating qualified traffic
A Podcast Production Agency was spending over $10,000 a year on SaaS transcription costs. We built ScribeKit, a custom transcription tool that brought that cost down to under $2 per project. The SaaS almost fit, until you looked at what it actually cost at scale. This is the internal tool replacement pattern: the category exists, the pricing doesn't work for how you actually use it.
Internal Tool Replacement
3 weeks
Media Production
Creating ScribeKit: From $10K+ in SaaS Costs to Under $2 per Project
Podcast Production Agency
A podcast production agency was spending thousands annually on transcription software with per-user licensing, credit-based pricing, and limited collaboration features.
Cost Reduction
From $10K+/year to <$2/project
Eliminated recurring SaaS fees and pay-per-credit pricing
Team Collaboration
100% improvement
Shared workspace replaced shared logins to the same account
Feature Control
Full ownership
Foundation for custom features built to their exact workflow
Nekst needed a marketplace MVP with an admin approval layer. Not a simple directory. A two-sided product with submissions, approvals, and a browseable front end for users. We designed and shipped the directory and the admin tooling together, as one coherent system, rather than bolting a back-end panel onto a front-facing site after the fact.
MVP Development
4 weeks
Real Estate Technology
Building Nekst Directory: A Two-Sided Marketplace MVP for Real Estate Professionals
Nekst.com
A real estate transaction platform needed a professional directory to connect agents with qualified transaction coordinators, admins, and service providers while maintaining quality through vetted profiles.
Time to Market
4 weeks from concept to launch
Rapid MVP development to test market demand
Quality Control
Admin approval workflow
Built-in vetting process to maintain high professional standards
Foundation for Growth
Scalable architecture
Designed for expansion based on early user feedback
You can see more work like this across our case studies and projects.
Engagement shape and investment
We structure portal engagements two ways depending on what you're building.
Internal Tool Replacement is the right fit when you're replacing a SaaS tool or fixing an ops workflow. Fixed scope. Typically $12-20K over 3-4 weeks. You get a designed, production-ready tool and you own the code when it's done.
UX-First MVP is for portals that are customer-facing or are the product. CAS and Nekst are both examples of this. Typically $15-25K over 4-6 weeks. The extra scope comes from the prototype phase and the multi-role complexity that customer-facing products carry.
For portals that are live and need continuous design work, we offer a monthly design partner retainer starting at $4,995. The right sequence is almost always a fixed project for the first build, then a retainer when you're in iteration mode. Running the initial build on a retainer takes longer and costs more. Start clean, ship clean, iterate from there.
You own the code. Always.
Questions worth answering before we talk
Is the portal overhead, or is it how you sell and deliver? If customers or partners live in it, treat it like product design, not an admin panel.
Where does the current process break? Spreadsheets, shared logins, seat costs, or a Retool UI nobody wants to use for eight hours? Bring that story, not a feature dump.
Who has to trust this UI? Internal ops only, or employers, candidates, vendors, clients? The audience changes the bar for polish.
Do you need to own the codebase? If the answer is yes within a year, don't optimize for the cheapest first version on a locked platform.
Book a discovery call and bring the workflow that's broken, not a feature list. The goal of the first conversation is to understand the actual problem so we can tell you honestly whether you need custom, Retool, or something else entirely.