Perspective on SaaS providers

 

The narrative that “AI will make SaaS obsolete” misses the real shift. AI isn’t replacing SaaS, it’s rewriting its economics. Let’s examine it in little bit detail.

• From Features to Outcomes: Traditional SaaS sold tools you operate. AI-native platforms deliver autonomous execution. Agents don’t just assist—they generate leads, draft outreach, optimize campaigns, and run workflows end-to-end. Value shifts from “what the software does” to “what it delivers.”.

•  Pricing Models Are Resetting: Per-seat licensing loses relevance when one AI agent replaces multiple users. Expect hybrid structures (subscription + usage + outcome-based) and tighter pressure on revenue predictability.

• Rise of AI-native competitors: There will be two classes of SaaS providers. Incumbents – tweaking the existing offerings to accommodate AI and new players – developing AI native systems from scratch. If incumbent do not overhaul SaaS architecture in big way, they may become glory of past.

•  The “Build In-House” Mirage: AI slashes dev costs, tempting mid-market teams to ditch vendors. But TCO, compliance, security, and ongoing maintenance will likely push many back to established SaaS ecosystems.
•  Consolidation & Verticalization: AI will compress “SaaS sprawl.” Horizontal platforms face margin pressure, while vertical/specialized providers with proprietary data and deep workflow integration will strengthen.
•  GTM Still Dominates Cost Structure: AI accelerates engineering, but sales, marketing, and enterprise trust-building remain the largest cost centers. Code is cheap. Distribution and adoption are hard.
•  Agent Reality Check: Non-deterministic outputs and evaluation complexity mean AI is currently a powerful automation layer—not a full replacement for mission-critical systems. Governance and quality control remain non-negotiable.

 In conclusion, large incumbents will survive, but “seat growth” will slow, pricing power will compress, and AI-native challengers will redefine categories. The new competitive moat isn’t features or code, it’s workflow ownership, domain expertise, and outcome accountability..

What do you think!!!

Widgets – My Dream SaaS

On a web page there are various ways by which a user can provide data as input. For this purpose HTML provides some elements (I will use “Widget” as general term).

1. Text Box
2. Text Area
3. Password
4. Hidden Field
5. Option Button
6. Radio Button
7. Selection/Combo Box
8. File select
9. Button
10. Date and Time Box (HTML 5)
11. Color Chooser (HTML5)
12. Calculated Text Box  (HTML5)

HTML specification specifies structural (e.g. size, dir, alt, etc.) and behavioral (e.g. formaction, etc.) attributes (Ref: https://developer.mozilla.org/en-US/docs/HTML/Element)

Java Script defines events pertaining to each widget and CSS venture into rendering part. 

From a SaaS platform perspective this approach poses few challenges:

• SaaS developer need to know three paradigms
• SaaS developer need to code to make a business application ( from client side perspective)
• Difficult to achieve Drag & Drop and Configuration Only approach to design and develop a business application
• Few of the widely used widgets (e.g. Tree, Grid, etc.) are missing from HTML specification
• The difference between Text Box, Text Area, Password and Hidden Field are not fundamental but semantic. Similar analogy can be drawn between Option Button and Radio Button.

So what is the solution!!

Solution is pretty simple. Reclassification of Widgets with few additions in terms of new widgets and providing a mechanism to configure widgets so cover HTML, Java Script and CSS defined attributes (and few additional) at one place.

Let us list widgets:

1. Text Box
2. Selection Button
3. Selection List
4. DateTime Box
5. Scroller
6. File Chooser
7. Button
8. Color Chooser
9. Tree
10. Grid
11. Tree Grid
12. Graph

Let us have brief thoughts about each widget.

 

Text Box: This widget should represent Text, Text Area, Password and Hidden HTML elements which are essentially described via INPUT tag and its TYPE attribute.

Selection Button: This widget should cover Option Button and Radio Button of HTML

Selection List: This widget should serve the purpose of Selection box.

DateTime Box: This widget covers INPUT tag with type representing date and/or time in HTML5.

Scroller: This widget does not have any counterpart in HTML but certainly there are many cleaver implementation of similar functionality using HTML, CSS and Java Script.  The nearest counterpart is JSlider object in Java.

File Chooser: This widget has one to one relationship with HTML Input tag and type attribute as file.

Button: This widget represents Input tag and type attribute as button and Button tag of HTML.

Color Chooser:  This widget represents Input tag and type color in HTML 5 and JColorChooser object in Java Swing.

Tree: This widget has no direct correspondence in HTML specification. The nearest relative is JTree object in Java Swing.

Grid: This widget has no direct correspondence in HTML specification. The nearest relative is JTable object in Java Swing. 

TreeGrid: This widget has no direct correspondence in HTML and Java Swing specification. The nearest match is http://www.treegrid.com/treegrid/www/

Graph: This widget has no direct correspondence in HTML and Java Swing.

Before digging deep into each widget let us set few ground rules:

• Each widget should be designed in such a manner that user experience related aspect should be configurable.
• Different aspects of user experience are:
  
  1. Basic definition and structural aspects such as ElementID, Value, DefaultValue, etc.
  2. Event and Gesture handling. How a widget will react to an event or gesture (in case of touch sensitive screens).
  3. Audio and Visual aesthetics of widget. The attributes defined here might be over ridden by scene (will define Scene later) level definitions.
  4. The widget configurability should also cover interaction with persistence layer to avoid coding to minimum.
• The definition of widget should be able to handle multilingual, localization, multi device and multi interaction aspects.
• Definition of widget should be expandable to accommodate future innovations.  Here ask is not for future proofing but for expandability.

Let us cover each widget one by one before moving to next topic.