When reviewing system development estimates, lines like "Environment Setup," "Architecture Design," and "Common Feature Implementation" usually appear near the top. Despite accounting for a sizable percentage of the total quote, very few clients can explain what work these line items actually entail.
In September 2026, AWS officially released "Nx Plugin for AWS 1.0." Featuring generators for individual components—from APIs, websites, and databases to AI agents and MCP servers—it is a tool that generates deployable scaffolding. Furthermore, infrastructure definitions (CDK or Terraform), WAF protection, access logs routed to CloudWatch, and X-Ray tracing are included right out of the box.
The top lines on development estimates are quietly beginning to lighten.
The nature of "common feature implementation" has changed
Until now, the first several weeks of building a new system were mostly consumed by tasks like the following:
- Deciding on project architecture and configuring folders and build settings
- Implementing shared boilerplate for authentication, logging, and monitoring
- Writing infrastructure as code and getting it into a deployable state
- Connecting type definitions so they can be shared between frontend and backend
Among these, folder structures and standard connection boilerplate are relatively easy to reuse. On the other hand, authentication methods, monitoring requirements, and network constraints vary by project. You must distinguish between tasks that can be eliminated through templates and tasks that require bespoke design.
When tools like this become standardized, the value of those internal proprietary assets declines. This is because recommended configurations are provided directly by official sources, complete with initial security and observability settings. The basis of comparison shifts beyond whether a vendor has templates to how well they adapt them to your company's requirements.
Where will your money go instead?
Scaffolding becoming fast and free does not necessarily mean quote totals will drop. It simply shifts where the weight lies. There are three destinations where that weight is moving:
First is requirements scoping. Scaffolding will not decide "what to build." In fact, as building becomes faster, incidents where teams start developing before defining requirements will only increase. This remains fundamentally human work. We outlined what clients should prepare beforehand in Client Guide to Successful Outsourced Software Development.
Second is tailoring generated scaffolding to your company. Scaffolding provides generalized solutions. Connecting to your existing systems, migrating legacy data, and adapting to internal authorization schemes cannot be resolved out of the box. Designing these integrations is the true substance of custom development.
Third is operations and handoff. There is no guarantee that the person who generated the code fully understands its internal workings. If tool-generated output is pushed to production without anyone reading it, it will become unmaintainable within six months. This follows the exact same pattern seen with AI-generated code, as detailed in When 80% AI-Written Code Rots in Six Months.
Three questions to ask when receiving an estimate
To confirm whether that weight has shifted, try asking the following three questions. The way they answer will reveal whether they are operating under current realities.
- "What is the basis for the initial setup effort?" Are they using official scaffolding and tools, their own internal templates, or writing from scratch? Any approach is acceptable, but being able to explain the reason for the choice is what matters. If all you get back is "This is how we always do it," the hours are simply being billed out of habit.
- "What monitoring and logging are included in the initial state?" These areas tend to be treated as afterthoughts, yet retrofitting them later is expensive. If they use tools designed to include them from the outset, this line item should be lean.
- "What is the review scope for generated code?" Whether they review tool-generated sections or only the code they wrote themselves dramatically alters your post-delivery risk profile.
Note that the goal of these questions is not to haggle over prices. Even for the exact same total amount, whether the bulk is allocated to initial setup or to requirements and operations completely transforms the post-delivery outcome. You should evaluate the distribution, not just the total sum.
"Default settings included" does not mean "tailored to your company"
A major selling point of these tools is that recommended configurations are included right from the start. This genuinely provides value, as it cuts down on the effort of setting up baseline monitoring and logging from scratch each time.
However, what is included is generic recommended configurations. Whether they are correct for your business is an entirely different matter.
| What is included | What to verify |
|---|---|
| Network communication protection settings | Whether it matches what your company must safeguard |
| Access logs | Whether retention periods and storage locations match internal policies |
| Request and process tracing | Whether captured traces inadvertently contain personal data |
In particular, log retention periods pose problems in two opposite directions if left at default values. If too short, incidents cannot be investigated; if too long, storage costs balloon unexpectedly. Both issues are typically discovered several months into production.
Before final handoff, ask for a list of settings left at their default values. A vendor that can promptly answer "We are using all defaults as-is" is at least tracking them. If they cannot produce a list, there is a chance no one has inspected the contents.
The other side of building faster and cheaper
There is one more aspect clients should keep in mind.
These tools are provided in formats directly callable by AI coding agents. In other words, we have reached the point where asking an AI to "build this architecture" spins up the foundational scaffolding without human hands touching the code.
What easily occurs here is that as development throughput increases, the project scope balloons accordingly. What started as a single feature turns into three under the pretext of "let's add this too while we're at it." Fast building comes hand in hand with the difficulty of avoiding overbuilding. Expand scope only after determining who will maintain it post-delivery. What to write into contracts is covered in It Does Not End with Delivery.
What to do next
If you are currently obtaining or comparing estimates, calculate what percentage of the total quote corresponds to "Initial Setup." There is no universal pass/fail threshold based solely on percentage. Compare quotes by asking for the breakdown among work eliminated by scaffolding, bespoke architecture, and validation/operations.
Next, write down any requirements that remain unsolidified first. In an era where scaffolding takes minutes, what delays projects is not technology, but unresolved specifications. Taking time upfront to resolve these will ultimately prove less expensive.
At GleamHub, we assist with scoping development requirements, validating estimate reasonableness, and designing AWS architectures through our Development, AI, and Automation consulting services. Because optimal architectures vary by requirements, we provide customized estimates. Please reach out via Contact Us.
Sources
- AWS announces Nx Plugin for AWS for scaffolding full-stack applications — AWS What’s New
- Build full-stack AWS applications in minutes with AI-powered scaffolding — AWS Open Source Blog
- AWS Open-Sources 'Nx Plugin for AWS 1.0': AI Generates Baseline Full-Stack AWS App Code End-to-End Across Security, Observability, and Infrastructure — Publickey
- awslabs/nx-plugin-for-aws — GitHub
