zeroCode is a software development framework that delivers tremendous savings in time and effort. It takes software development from a manual process to a highly scalable, automated model that offers infinite opportunities for custom work. Projects using zeroCode have shown productivity in the range of 80 to 100 FP (function points ) per person-month (tools-based development normally delivers 30 to 50 FP, hand-coding about 22 to 25). And productivity increases with project size.

• You can build an application fast
• You can build a fast application.

• zeroCode leverages the knowledge in the database schema tremendously, using it to build the basic "plumbing" for applications.
• Many commonly used business functions - security, sorting, searching, foreign-key dereferencing and relators, to name a few - are built into the environment, so that the effort needed to design or construct them reduces.
• Constructing even complex visual renditions is merely a matter of running the data model through a suitable "meta-template" in a few browser clicks. Most other products need significant time for each screen/page to be created.
• Constructing input and editing forms has an even bigger payoff, since they are automatically built up front. Most other products offer little in this aspect.
• Filters and action sequences provide reusable abstractions at a much higher level than the Java object - much closer to a domain expert's level of thinking.
• Automatic computation of dependencies between transaction sections saves a great deal of time and effort on the part of the designer.
• Data ports offer easy aggregation of multiple data sources within one rendition.

• The zeroCode engine is based on sound architectural choices and a conscious effort to adhere to the principles of efficient algorithm design. For example:
• Data structures are precomputed and are not recomputed unless likely to have changed. Global and object-level configuration details are computed when first needed and maintained in memory through the application's run.
• "Lazy evaluation" is used to maximum benefit, thus providing a "pay-as-you-go" effect. For example, the data structures for a resource/transaction are only computed if the resource is accessed.
• Time-varying data are cached as necessary (in line with default policies and designer choice), saving significant time for database access. The caching philosophy conforms to the reality that memory is cheap but time is not.
• Faster but more complicated internal algorithms are preferred over simpler, easier-to-implement variants.
• Most internal business objects are immutable, i.e., once created, they do not maintain internal state between method calls. This makes them inherently thread-safe. It also greatly reduces the need for synchronizing threads, thus minimizing lock bottlenecks and exploiting inherent parallelism.
• The design minimizes sharing state between threads: the only such shared state involves configuration data and very low-level locks for connection pool control. This choice also mitigates the need to synchronize threads.
• An "optimized SQL" feature maximizes the number of needed attributes retrieved from each database access. This greatly reduces the number of database accesses, thus enhancing performance.
• The engine uses infrastructure components such as connection pooling, transaction control and threading to full effect. It can exploit an available application server, or use its own components for the same purpose