Question 1

What does Nexaces do?

Accepted Answer

We design, build and operate web systems for the public sector. Our capability areas are custom application development, enterprise content management systems, custom application and API engineering, data platforms and reporting dashboards, headless frontend applications, and Section 508 and WCAG accessibility compliance audits. Each one is described in full on the Services page.

Question 2

What makes Nexaces different from a web agency?

Accepted Answer

We do not hand a build over and move on. We build it, we run it, we support it. Fictbase and Doodrio are two SaaS products we designed, launched and operate ourselves, with real customers and real infrastructure, running today. Every engagement we take on is held to the same operational standard we hold our own products to.

Question 3

Who do you work with?

Accepted Answer

Public agencies and authorities, the organizations that serve them, and private clients whose systems carry the same requirements for security, uptime and accessibility. Our NAICS code is 541511, Custom Computer Programming Services, and our SIC code is 7371.

Question 4

Do you work with agencies outside New Jersey?

Accepted Answer

Yes. We are based in Branchburg, New Jersey and work remotely with clients elsewhere. Distributed delivery is how our own products are already run, so the tooling and the communication habits are in place rather than being set up for your project.

Question 5

How do we request a capability statement?

Accepted Answer

Use the contact form, email info@nexaces.com, or call +1-862-461-9994 and ask for one. Every channel reaches the same people, and the people who answer are the people who would do the work.

Question 6

What does a typical engagement look like?

Accepted Answer

Five stages. Discovery, to understand the requirement, the constraints and the people who have to use the system. Planning, which produces a scope, an architecture and a timeline. Design and build. Review and testing, including accessibility and security checks before anything goes live. Then launch and ongoing operation. You see working software at each stage rather than a status report about it.

Question 7

How long will a project take?

Accepted Answer

It depends on scope, on how many systems we have to integrate with, and on how quickly reviews and approvals come back from your side. We give an estimated timeline after discovery, once the requirement is understood well enough for the estimate to mean something. We would rather give you a date you can defend than a fast one you cannot.

Question 8

How do you handle changes to scope?

Accepted Answer

Changes are expected, particularly where a requirement is shaped by regulation or by a stakeholder who joins late. Small adjustments are absorbed as we go. Anything that moves the timeline or the cost is written down, priced and agreed before work starts on it, so nothing arrives as a surprise at invoicing.

Question 9

How involved will our team need to be?

Accepted Answer

Enough to keep the system honest. We need access to the people who own the process being digitized, and timely feedback at review points. Beyond that we do not expect your team to manage us. Progress stays visible and we raise blockers rather than waiting to be asked about them.

Question 10

What is your security posture?

Accepted Answer

Security is not a step we add at the end of a project. It is a practice we run on our own products every day: two-factor authentication on administrative access, sanitized and validated input handling on every user-submitted field, PCI-scope-minimized payment processing through Stripe so card data never touches our own servers, and OAuth-based authentication where applicable. The same practices carry into every engagement we take on.

Question 11

How is our data handled during an engagement?

Accepted Answer

We work with the minimum data required to do the job. Where testing needs realistic data we prefer anonymized or synthetic sets, and where that is not workable we agree handling terms in writing before any data moves. Access stays limited to the people actually doing the work.

Question 12

Who has access to our systems?

Accepted Answer

Only the people working on your engagement, and only for as long as they need it. Administrative access is protected by two-factor authentication. You own the accounts and the infrastructure and we work inside them, which means you can revoke our access yourself at any time without waiting on us to do it.

Question 13

Do you hold certifications or formal registrations?

Accepted Answer

Ask and we will tell you precisely what we hold, rather than implying more. Our NAICS code is 541511 and our SIC code is 7371. If your procurement process requires particular registrations, certifications or insurance, raise it early and we will confirm our position in writing before you spend time preparing a submission around us.

Question 14

What accessibility standard do you build to?

Accepted Answer

WCAG 2.1 AA by default, for nexaces.com and for delivered client work alike. We treat accessibility as a build-time requirement, not a post-launch audit item, because retrofitting it costs more and produces a worse result for the people who depend on it.

Question 15

Can you audit a system we already have?

Accepted Answer

Yes. Section 508 and WCAG accessibility compliance audits are one of our capability areas. We apply universal design principles across public digital assets and bring them into alignment with state and federal web accessibility mandates. An audit from us tells you what is failing, why it matters to a real user and what it takes to fix, rather than handing over a list of automated warnings.

Question 16

Does accessibility work slow a project down?

Accepted Answer

Not when it is built in. The cost people associate with accessibility is almost always the cost of retrofitting it. Keyboard and screen-reader aware patterns chosen at design time are simply how the interface gets built, and they cost nothing extra at that point.

Question 17

What technologies do you work with?

Accepted Answer

PHP and Laravel on the server side, React and JavaScript for frontends, Drupal and WordPress for content-managed portals, and SQL data stores behind reporting and dashboards. We choose from what fits the requirement and what your team can maintain after we hand over, not from what happens to be fashionable.

Question 18

What is a headless frontend, and why would we want one?

Accepted Answer

It separates the interface the public uses from the heavy data systems behind it. The citizen-facing application stays fast and available even while the backend is under load or in maintenance, and the two can be changed independently instead of being released together. We build these with React.

Question 19

Can you integrate with the systems we already run?

Accepted Answer

Yes, and that is most of the work. Payment tools, licensing and permit forms, OPRA records handling, identity providers and third-party APIs. Integration is where public-sector projects usually run into trouble, so we scope it deliberately at the start rather than treating it as a detail to be worked out later.

Question 20

Will the system work on phones and assistive technology?

Accepted Answer

Yes. Responsive layouts and assistive-technology support are part of the build rather than an option on top of it. A public-facing system that only works properly in a desktop browser is not finished.

Question 21

What happens after launch?

Accepted Answer

We keep running it. That is what we build it, we run it, we support it actually means. Post-launch work covers monitoring, updates, fixes, and the changes that only surface once real users are inside the system. Support terms are agreed as part of the engagement rather than sold back to you afterwards.

Question 22

Can you take over a system someone else built?

Accepted Answer

Often, yes. It depends on the state of the code and on whether we can get proper access to it. We will look at it and tell you honestly whether taking it on, rebuilding part of it or replacing it is the better use of your budget, including when the honest answer is not the one that earns us the most work.

Question 23

What happens if something breaks?

Accepted Answer

You contact us and we deal with it. Response expectations are written into the support arrangement rather than left vague, so both sides already know what urgent means before something urgent happens.

Question 24

How do you price work?

Accepted Answer

Per engagement, after discovery, based on scope and complexity. We quote against a written scope so the number is traceable to something specific rather than to a feeling. If you need a figure before the requirement is understood, we will give you an honest range and say plainly that it is a range.

Question 25

How is payment structured?

Accepted Answer

Typically a deposit followed by defined milestones, with terms adjusted to the engagement and to your procurement process. We would rather fit the way your organization already pays for work than ask you to make an exception for us.

Question 26

Is there a minimum project size?

Accepted Answer

No fixed minimum. We take on focused pieces of work such as an accessibility audit, a single integration or one application as readily as a full platform build. What matters is whether it is work we can do well and still stand behind afterwards.

Question 27

Who is Nexaces?

Accepted Answer

An independent software engineering practice based in Branchburg, New Jersey. We design, build and personally operate the systems we deliver, not only up to handoff but for as long as they are in production.

Question 28

What proof is there that you can operate what you build?

Accepted Answer

Fictbase and Doodrio. Two independently run SaaS products we designed, launched and operate ourselves, with real customers, real infrastructure and real support, running today. They are not work we did once for someone else. They are systems we are accountable for right now.

Frequently Asked Questions