Our Work
Custom software engineers since 2013 —You know the people who build A.I.
Thirty years of engineering & building systems that companies run on — and that they own outright when we’re done.
Below, enjoy our: client engagements, the systems we build for ourselves, and over two decades of delivered work standing behind both. The rest of the portfolio, including the parts we don’t publish, comes on the call. Today we build A.I.
Selected work
A Custom CRM for Veterans Advocacy
Case Study 01
Client: U.S. veterans-advocacy firm
Sector: Veterans advocacy · VA disability claims
Engaged: 2026 – present
Ten workflow phases · Three portals · Five roles · Discovery to beta in about nine weeks
The problem
A veterans-advocacy practice was running a high-stakes, legal-adjacent workflow on spreadsheets and scattered tools.
No single view of where a client sat in the claims process. No audit trail when contact details changed. No structured way to track conditions, filings, denials, or rating percentages. C&P exam scheduling was manual and prep calls were reactive. Sensitive documents — medical records, lay statements, Nexus letters, DD-214s — were handled with no classification, no access controls, and no safe delete. Staff had no way to know when a client had last been contacted.
The exposure: dropped claims, missed exams, and no way to measure success across the practice.
What we built
A three-portal CRM built around the practice’s actual workflow — not a generic template with a veterans skin.
- Role-based access across five roles — Managing Director, Case Manager, Medical Assessor, Contract Manager, Admin.
- Condition tracking with filed / denied / percentage / notes recorded per condition.
- Document classification on upload — decision letter, lay statement, Nexus letter, medical record, DD-214.
- Client-safe delete — clients can hide but never delete; staff deletion requires manager approval.
- Audit trail on contact changes, with restricted edits on identity fields.
- Touch-date tracking with overdue-contact alerts, so no client goes quiet unnoticed.
- Mobile-friendly staff interface for updates from the field.
Built around how the practice actually works
The system tracks every client through ten workflow phases — collapsed from an earlier thirteen-phase draft in direct response to the team’s feedback.
Redundant phases were removed and terminology was rewritten to match the language the team already used. That refinement happened live, across two deep-dive working sessions.
Outcome
- A manual, spreadsheet-driven practice consolidated into one auditable system, discovery to beta in about nine weeks of active development.
- Ten workflow phases, three portals, five roles, and full document classification in place of ad-hoc file handling.
- The practice reports 25 veterans reached a 100% VA disability rating over the period following February 2026.
Why SBLOCK
They didn’t need a subscription. They needed a system built around a practice that already worked.
- Custom build, no vendor lock-in. Every phase, role, and field reflects their operation.
- Domain-native. The system speaks C&P exams, Nexus letters, DD-214s, and rating percentages — not consultant-ware with the vocabulary swapped out.
- Full-stack delivery. Web application, role-based authentication, document workflows, offsite backups, analytics — one team, one point of contact.
- A partnership, not a hand-off. Requirements changed across three working sessions and the build adapted each time.
A Branded Event Platform, Four Years Running
Case Study 02
Client: Nationally recognized live-entertainment promoter
Sector: Live entertainment · Event management
Engaged: 2022 – present
Four coordinated surfaces · One shared backend · Live and maintained four-plus years
The problem
A live-entertainment promoter needed Ticketmaster-class functionality without the Ticketmaster relationship — a branded, custom ticketing and event platform where the promoter, not a third-party marketplace, owned the customer, the data, and the content.
- No scalable, branded ticketing system.
- No mobile purchase flow for attendees.
- Event operations, content management, and ticket sales lived in separate places.
- A non-technical team had to run routine event updates without calling an engineer every time.
- Marketing needed to flow through a platform the client owned — not through a social network where posted content becomes the network’s asset.
What we built
Four coordinated surfaces on a single shared backend, each scoped to who actually uses it.
Desktop for operations. Mobile for attendees. A content admin scoped tightly enough that the client’s marketing director updates images, dates, and events without touching code. One backend, four front doors.
Why it isn’t a Ticketmaster skin
- Third-party brand and checkout — Branded end to end; the client owns the customer
- Generic admin, if any — Admin scoped for a non-technical team
- Content and event management separate — Content and event management in one place
- The platform owns the data — The client owns the data
- Per-ticket revenue share — Flat build plus maintenance
Outcome
- Live and maintained for four-plus years. For a platform a business runs on, durability is the proof that matters.
- Mobile expansion active — iOS and Android in active expansion, on the same shared backend.
- Training and handoff included. A video tutorial series plus hands-on admin sessions, so the client’s marketing director runs routine updates independently and SBLOCK is called for the larger, vendor-heavy events.
- Owned content pipeline. Blog-first publishing on the client’s own platform, protecting their copyright and their search visibility before content reaches social.
Why SBLOCK
They didn’t get a ticketing subscription. They got a platform their business runs on.
- A durable partnership. Four-plus years of uninterrupted maintenance, not a one-and-done project.
- Custom build, not SaaS lock-in. The client owns the brand, the customer data, and the roadmap.
- Full-stack delivery. Desktop operations, mobile, content admin, and the public content pipeline — one team, one point of contact.
- Handoff by design. Tutorials and training so the client is not dependent on us for routine work.
- Committed through change. When a test event slipped, we stayed engaged and supported the reschedule rather than billing a walk-away.
A Nonprofit Platform Built to Take Donations, Not Maintenance
Case Study 03
Client: A U.S. veterans 501(c)(3)
Sector: Nonprofit · 501(c)(3) veterans services
Engaged: 2025 – present
Platform migration · Custom theme · Card donations · A five-plugin ceiling, held
The problem
A newly IRS-approved 501(c)(3) serving U.S. veterans — housing assistance, emergency shelter, and disaster relief — was running on a hosted website builder. That is a reasonable place to start and a bad place to stay.
The site could not take donations the way the organization needed to take them. The organization did not own the platform, could not extend it, and was paying a subscription for the privilege of being limited by it. And the people who would have to run it day to day were volunteers and officers with a mission to deliver, not a content management system to learn.
Nonprofits fail at this in a specific way: they end up with a site that is either too rigid to change or so overloaded with plugins that changing it is dangerous. Both outcomes cost the same thing, which is donations that never arrive.
What we built
A platform migration off the hosted builder onto WordPress the organization owns outright, with a custom theme and a deliberately short list of moving parts.
- A custom theme built for this organization, not a marketplace template bent into shape — so layout and content changes are edits, not workarounds.
- Card donations through a payment gateway, wired into the store so giving, merchandise, and inventory run through one system instead of three.
- Member accounts and profiles for supporters and program participants.
- Backup and restore configured from day one, not added after the first scare.
- Container-based hosting behind an Nginx reverse proxy, with the production layout mirrored locally so a change can be tested before it reaches the live site.
The constraint we imposed on ourselves
The build runs under a five-plugin ceiling. Anything the organization needs beyond those five gets built into the theme instead of bought as a sixth dependency.
That is not minimalism for its own sake. Every plugin is a vendor with a key to the site, an update cycle nobody controls, and a security posture nobody audited. For an organization run by volunteers, the difference between five dependencies and fifteen is the difference between a site that keeps working and a site that quietly breaks between board meetings.
Outcome
- The organization owns its platform, its theme, its data, and its donor records — no subscription tier gates what it can do next.
- Donations, merchandise, and inventory run through one system with one place to reconcile them.
- Routine content is maintained by the organization’s own people, not billed back to us.
Disclosure: SBLOCK’s principal serves as an officer of this foundation. We name that here rather than present the engagement as arm’s length — the work is real, and so is the relationship.
Why SBLOCK
- We migrate off platforms without losing the site. The move was a rebuild onto owned infrastructure, not an export and a hope.
- We build the dependency budget into the design. Fewer vendors is a decision made at the start, and it is the reason the site is still cheap to run.
- Mission-first organizations get the same engineering as commercial ones. Backups, staged testing, and an owned codebase are not enterprise luxuries. They are what keeps a volunteer organization from losing a year of work to an update.
What we build for ourselves
A portfolio of client work cannot answer every question, because the most revealing parts of a client system are the parts we are not free to show. These are systems SBLOCK built for itself. No signature stands between you and the detail.
Real-Time Speech Translation to Your Earbuds
Built by SBLOCK
Built by: SBLOCK — own product
Sector: Consumer AI · Mobile · Speech
Status: 2026 – in active development
Three AI services chained behind one API · 2.2 seconds end to end, measured · Native Android client
The problem
Every translation app on the market makes you stare at a phone. You hold it up, wait, read a screen, then look back at the person you are actually talking to. That is fine for a menu. It is useless in a conversation.
The hard version of the problem is audio-first and hands-free: hear foreign speech, get it back as a natural voice in your own language, through the earbuds you are already wearing, fast enough that the conversation does not stall. Which makes it a latency problem before it is anything else. Past roughly three seconds, people stop waiting and start talking over each other.
What we built
TranslateMate is SBLOCK’s own product — a platform that captures speech, runs it through three AI services in sequence, and returns synthesized translated audio to the user’s earbuds.
- A native Android client in Kotlin and Jetpack Compose, built around audio rather than a screen.
- An orchestration API in Express, TypeScript, and Prisma that owns the three-stage chain, so the client never talks to a model vendor directly.
- A vendor-swappable pipeline. Each stage sits behind our own interface. Any of the three services can be replaced without touching the client.
- A latency budget treated as a requirement, not a hope: 3.0 seconds at P95, measured per stage, with the per-stage numbers visible so the slow link is always obvious.
The number we build against
First end-to-end translation, English to Spanish, measured 2026-03-06:
- Whisper — speech to text — 852 ms
- DeepL — translation — 424 ms
- ElevenLabs — text to speech — 861 ms
- Network overhead — 59 ms
- End to end — 2,196 ms
Three vendor round trips and a mobile network, inside 2.2 seconds, against a 3.0-second target.
Status
TranslateMate is in active development. The API and the Android client are built and running; this is not an app-store release and we do not present it as one. We are showing it because it is ours, the numbers are ours, and it is the clearest example of the kind of system we build.
Why this is in our portfolio
Client case studies cannot show you certain things. This one can.
- We ship AI systems that have to be fast, not demos that are impressive when nobody is timing them.
- We orchestrate multiple model vendors behind one interface, which is what keeps a product from being hostage to a single provider’s pricing or uptime.
- We measure. A latency table per stage is the difference between engineering and optimism — and it is the same discipline we bring to a client build.
The Platform We Run Our Own Business On
Built by SBLOCK
Built by: SBLOCK — own product
Sector: WordPress platform engineering · CRM · Analytics
Status: 2025 – present, in production
21 modules · 29 database tables · 60 classes · One plugin in place of a stack of vendors
The problem
Every WordPress site ends up the same way. A dozen plugins from a dozen vendors, each with its own update cycle, its own security posture, its own idea of where your data goes, and its own way of breaking when another one updates. Analytics from one company, forms from another, SEO from a third, a CRM bolted on from a fourth — none of them aware of each other.
The result is a site nobody fully understands, held together by whichever vendor last shipped a patch. When something breaks there is no single place to look, and when a vendor sells the business or abandons the plugin, that decision becomes yours to clean up.
What we built
SBLOCK Digital is our own platform, and we run our own business on it. It replaces the vendor stack with one package we control end to end.
What is in it
- Contact and pipeline — CRM · contacts · interactions · deals · collections · custom fields and lists
- Operations — Workflows and stages · tasks · calendar and appointments · documents and signatures
- Acquisition — SEO · SEM campaigns and attribution · social sharing and tracking · social sign-on
- Communication — Forms and submissions · email templates and logging · spam protection · reCAPTCHA
- Governance — Roles and capabilities · audit log · dashboard and analytics
Verified against the plugin source at version 1.12.0: 21 modules, 29 database tables, and 60 classes, with an abstract module base class and a class-map autoloader so a module can be switched off without touching the others.
The parts that matter to a buyer
- Dual-source analytics. Traffic is measured both from the browser and from the server’s own access logs, so a blocked script does not mean a blind spot — and bot traffic is identified rather than counted as visitors.
- An audit log across sensitive changes, not just a change date on a record.
- Role and capability control as a module, so who can see what is configuration rather than a code change.
- Conflict detection at load. The platform disables its own SEO module if a legacy SEO plugin is active, instead of quietly fighting it for control of your page titles.
- One settings surface, one update, one place to look when something needs tuning.
Why this is in our portfolio
This is the honest version of the “where does your data go” answer.
- We use what we sell. sblock.cc runs on this. When we tell you a platform’s defaults were reviewed rather than assumed, this is the platform we reviewed first.
- It is a working answer to plugin sprawl — one maintained package, GPL-licensed, with no third-party vendor holding your contact records.
- It shows the same shape as our client work. Roles, audit trails, workflow stages, and document handling are the pieces custom business systems are actually made of. We build them often enough that we built them for ourselves.
Also in the portfolio
A South Florida municipality — GeoSpatial Data consulting and GeoAI advisory. 2024 – present. Municipal-grade data work, ongoing.
A New York based non-profit — custom software development and ongoing management. 2020 – present, a six-year relationship.
A U.S. herbal-supplement brand — ecommerce storefront, brand system, and managed hosting. Ongoing. Catalog, checkout, and hosting run as one engagement.
Three Decades of Delivered Work
Building since 1993. What follows is sector-level on purpose: it is work delivered by SBLOCK and by SBLOCK’s people across earlier engagements, and most of it belongs to organizations that have no reason to be named on our website.
- Home-care franchise network — Multi-site web application on ASP.NET and SQL Server (2000s)
- Aerospace engine-parts manufacturer — Engineering intranet plus a data cleansing and migration effort (2000s)
- Diversified industrial holding company — Full corporate platform — governance, news, investor-facing pages (2000s)
- International payments provider — Multilingual platform across four languages (2000s)
- Regional hospital — Public website and content platform (2000s)
- Religious archdiocese — Online giving platform with payment-gateway integration (2000s)
- Global travel-technology company — Multi-city event microsites and campaign delivery (2000s)
- Mobile marketing and messaging firm — Corporate platform and creative production (2010s)
- Accounting and advisory firms — Several complete platforms with administrative back ends (2000s – 2010s)
- Marine and superyacht services — Purchasing, marina operations, and contact systems (2010s)
- Telecom construction at national scale — Back-office system joining field, financial, GIS, ERP, and workforce data for fibre and wireless build-outs (2010s – 2020s)
- Architecture practice — Custom web application and database, discovery through delivery (2010s)
- Independent retail and ecommerce — Custom storefronts with card-payment gateway integration (2000s – present)
What isn’t on this page
A portion of our work does not appear in public, and that is deliberate.
Some of it sits under agreement. Some of it is internal to a client’s operation and would identify them the moment it was described in enough detail to be interesting. Some of it we simply do not discuss, which is the same courtesy the next client gets.
So treat this page as a selection, not an inventory. If you want to see the work that maps to your problem specifically — including the parts that never get published — ask on the call. We will walk you through it there.
How We Work
Three things a portfolio of finished projects can’t tell you, and that decide most engagements.
Where your data goes
Most software risk in 2026 isn’t a breach. It’s a platform doing exactly what it was designed to do — calling home, enriching your contact records against a third-party service, syncing something you didn’t know was syncing — all of it documented somewhere in a settings page nobody opened.
We audit the platforms we deploy for outbound data behavior, including the ones we run our own business on. Before a system goes into production we establish:
- What talks to the outside. Every scheduled job, integration, and enrichment service that makes an external call, and what it sends.
- Which of those are on by default. Free and community-tier software frequently ships data-sharing enabled, because that’s the commercial model. Defaults get reviewed, not assumed.
- Where the boundary is enforced. Outbound restrictions belong at the network layer, not only in an application checkbox that a vendor update can quietly reset.
- What we can turn off and still ship. Convenience features that leak data get removed, not documented as accepted risk.
What this means for you: you get a written answer to where your data lives, what leaves your environment, how long it’s retained, and what — if anything — it trains. If we can’t answer that about a component, we don’t put your business on it.
How we build
We build with the technology of now, AI. It is part of why a ten-phase claims system went from discovery to beta in about nine weeks, and we’re not going to be coy about it — by 2026 every serious shop is using these tools, and the ones claiming otherwise are usually just not saying so.
The part that actually matters is what surrounds it:
- Version control and review on everything. No unreviewed generated code reaches your production environment.
- Documentation written as the work happens, not reconstructed at handoff.
- Your repository, your infrastructure. The work product lives where you can reach it, during the engagement and after it.
- Tested against your real data, not a demo fixture. Systems that look right in a walkthrough and fall over on the actual dataset are the single most common way software projects fail.
And we’ll tell you where AI doesn’t belong. Plenty of the problems we’re brought in for are not AI problems — they’re an unmaintained system, a manual process nobody has mapped, or four tools that should be one. Selling you a model for that would be easy and wrong.
You own it, and you can run it
Every engagement is built to be handed over.
- You own the code, the data, the domain, and the roadmap. Built to spec, owned by you — not licensed back to you.
- Trained, not just delivered. On the event platform we built, the client’s marketing director runs routine updates independently after a tutorial series and hands-on admin sessions. We get called for the complex work, not to change a date.
- Access, audit, and backup from day one. Role-based permissions, audit trails on sensitive changes, and offsite backups are part of the build, not a later phase.
- Continuity is structural. Because you hold the code and the infrastructure and your team is trained on it, your business does not stop if we do. That is the honest answer to the question every buyer is right to ask before signing with any firm.
Why SBLOCK
Builder Since 1993
We have been building software globally for over thirty years — through the arrival of the commercial web, mobile, cloud, blockchain, and now AI. We were working with distributed ledgers and stable coins.
That matters for one practical reason. The most expensive risk in a custom software engagement isn’t the build; it’s the firm disappearing two years in, leaving a system nobody can maintain. Thirty years is the only honest answer to that, and very few firms in this market can give it.
One partner, end to end
Software, infrastructure, security, and media under one roof — so integration is our problem, not yours.
- Custom software — Web, desktop, and mobile applications · SaaS platforms, APIs, firmware
- Financial technology — Payment processing, POS, banking applications · smart contracts and distributed ledger
- AI and emerging technology — Machine learning deployments · IoT · workflow automation
- Digital media and marketing — Search, content-first distribution, performance measurement
- IT solutions and consulting — Full-stack consulting · cybersecurity audits and hardening · digital transformation
- IT hardware and infrastructure — Servers and colocation · fiber, LTE, 5G · surveillance · solar
Digital and physical security in the same engagement — cybersecurity alongside biometrics, surveillance, and access control. Few regional firms combine them, and buildings with both problems shouldn’t need two vendors.
Global
We are close enough to be on site when being on site is what the problem needs.
Support
24/7 support, and a direct line to the people who built your system — not a ticket queue.
What clients say
“SBLOCK successfully brought our company into the 21st century. I didn’t realize how much effort and resources we were wasting. Thank you!” — Michelle Chan, Procurement Manager, calibamboo.com
“A Website and Android application at a fraction of the cost of others. We still can’t figure out how you did it, but we appreciate it! Well done!” — Jude Phillips, CEO / Owner, GilChristAutomotive.com
“Without SBLOCK we would never have gotten this project off the ground. You really know your stuff.” — Mathew McCall, Sales Manager
Let’s talk about your system
Tell us what you’re running now and where it’s costing you. We’ll look at your whole IT picture — software first — and tell you what to fix, in what order, and what we’d do differently.
Request a Consultation
Or call +1 (800) 407-6875.