Design and Evaluation of TechLedger for Software Service Discovery and Comparison

Abstract

TechLedger is a web application for discovering, researching, saving, and comparing software services. It addresses a practical problem in technology selection: information about capabilities, releases, and pricing is spread across vendor sites, and users must keep their own shortlist while reviewing it. The application combines a React and TypeScript interface with a bundled catalog, Gemini-assisted research, and account workspaces stored in Neon PostgreSQL. This paper describes the implementation and examines the public repository at commit 5425d313. Static checks identify 81 services across 12 categories, of which 70 use template defaults for versions, pricing, and capabilities. Seven diagnostic queries illustrate the limits of substring search, and source inspection identifies a mismatch between verification labels and the evidence stored in a profile. These findings support a design that separates missing values from known facts and records evidence for individual fields. The paper also explains how saved services and comparison support a personal software stack. No user study or live research accuracy test is reported.

Introduction

This paper presents TechLedger, a web application designed to help developers research, organize, and compare technology services such as databases, cloud platforms, and AI tools in one workspace. It addresses the difficulty of comparing products when vendors use different terminology, pricing models, documentation, and release information.

Main purpose

TechLedger aims to:

• Provide a searchable catalog of technology services.

• Allow users to research individual services using AI-assisted web research.

• Save services and research results for later use.

• Compare up to three services or releases.

• Support both guest and authenticated workspaces.

• Keep research evidence and comparison information connected in one system.

The paper focuses on how the application connects its interface, data, research services, and user workspaces, while also examining the reliability limitations of the information it presents.

System architecture

TechLedger is built using React 19, TypeScript, Next.js, Vite/vinext, and Tailwind CSS. The system has:

• A client-side catalog containing baseline service records.

• Server routes for AI research, data enrichment, persistence, and currency conversion.

• Browser-based localStorage for guest workspaces.

• Neon Auth and PostgreSQL for authenticated user workspaces.

• Drizzle ORM for database interaction.

• Gemini with web-search and URL-context capabilities for AI-assisted research.

A shared Service data structure allows catalog entries, researched profiles, saved services, and comparison views to use the same underlying representation.

Workspace and data management

Guest users can store saved services, comparison selections, researched profiles, alerts, and preferences in their browser. Authenticated users can store this information in a database and access it from other devices.

However, guest data is not automatically merged into a new authenticated account. The shared data model also has limitations because provenance is primarily stored at the profile level rather than being attached individually to every price, capability, version, or claim.

AI-assisted research

Users can submit a service name to a research endpoint. The system provides the AI with relevant catalog information and asks it to research:

• Official documentation

• Pricing pages

• Changelogs

• Capabilities

• Versions and release information

The AI returns structured service information, which TechLedger normalizes and stores.

An important limitation is that structured AI output and search grounding do not guarantee factual accuracy. Source links allow users to investigate claims, but the system does not independently verify every price, version, or capability. The timestamp records when the research was performed but does not prove that every piece of information was current.

Comparison functionality

TechLedger allows users to compare up to three services or releases across:

• Overview

• Pricing

• Capabilities

• Releases

It can calculate percentage price changes when comparable numeric prices are available. However, the application does not independently confirm that prices use the same plan or billing unit.

Historical release comparisons also have an important limitation: selecting an older release changes the version and release date, but other attributes remain from the current service profile. Therefore, historical selections should not be interpreted as complete historical snapshots.

The application also provides USD-to-INR conversion using an external The search queries are diagnostic examples rather than a statistically representative benchmark, so the study does not claim a formal retrieval- TechLedger stores source URLs and research timestamps, it does not yet connect every individual claim—such as a price, feature exchange-rate service, but this is only an estimate and does not account for taxes, regional pricing, payment-provider rates, or provider-specific billing rules.

Saved services and alerts

Users can create shortlists of services, switch between grid and list views, compare or remove services, and export their selections as CSV files.

The dashboard and alert system are based on information already stored in TechLedger. They do not continuously monitor vendors for changes. Therefore, an alert or release item represents stored information rather than a verified, newly detected change from a provider.

Practical workflow

A typical intended workflow is:

Discover services → Research a service → Inspect sources → Save candidates → Compare services/releases → Export findings

For example, a developer could research and compare PostgreSQL, MySQL, and Redis before selecting a backend technology. However, the paper emphasizes that this workflow is an intended use case rather than a measured demonstration of improved decision quality or reduced research time.

Evaluation

The evaluation is primarily a static repository analysis of a specific implementation commit. The researchers examined:

• Catalog contents.

• Search behavior.

• Interface labels.

• Comparison logic.

• Browser storage.

• Export functionality.

• Alert rules.

Seven fixed search queries were used to inspect catalog-search behavior.

Importantly, the evaluation does not test the live Gemini research system, Neon authentication, database behavior, or hosted runtime. The search queries are diagnostic examples rather than a statistically representative benchmark, so the study does not claim a formal retrieval-accuracy rate.

Key contribution and limitations

The main contribution is an implementation account of a unified technology-research workspace that combines catalog browsing, AI-assisted research, saving, comparison, and persistence.

The major reliability limitation is data provenance. Although TechLedger stores source URLs and research timestamps, it does not yet connect every individual claim—such as a price, feature, or version—to specific supporting evidence. Consequently, users still need to verify important information themselves.

Conclusion

TechLedger connects service discovery, AI-assisted research, saved workspaces, and comparison in one application. Its shared service model allows the same candidate to move from browsing to a retained shortlist and a side-by-side review. The static evaluation also identifies limits that affect interpretation: most catalog entries contain template defaults, verification labels exceed the evidence recorded, and substring search misses common query forms. The next development step is to make the quality and age of each field visible, then evaluate researched profiles and user tasks. That would give users a firmer basis for deciding which tools belong in their software stack.

References

[1] V. Shinde, TechLedger, GitHub repository, commit 5425d313e193cc6d1bf2914924d129b366366503, 29 September 2026. https://github.com/gitvedhub/TechLedger/tree/5425d313e193cc6d1bf2914924d129b366366503 [2] M. A. Hearst, “Design Recommendations for Hierarchical Faceted Search Interfaces,” ACM SIGIR Workshop on Faceted Search, 2006. https://flamenco.berkeley.edu/papers/faceted-workshop06.pdf [3] N. F. Liu, T. Zhang, and P. Liang, “Evaluating Verifiability in Generative Search Engines,” Findings of EMNLP 2023, pp. 7001–7025, 2023. doi: 10.18653/v1/2023.findings-emnlp.467. [4] Google AI for Developers, “Grounding with Google Search,” Gemini API documentation. https://ai.google.dev/gemini-api/docs/google-search [5] Google AI for Developers, “Structured outputs,” Gemini API documentation. https://ai.google.dev/gemini-api/docs/structured-output [6] Mozilla, “Window localStorage property,” MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage [7] Neon, “Serverless driver for JavaScript and TypeScript,” release guide. https://neon.com/blog/serverless-driver-ga [8] Frankfurter, API documentation. https://frankfurter.dev/ [9] W3C, Web Content Accessibility Guidelines 2.2, W3C Recommendation, 2023. https://www.w3.org/TR/WCAG22/

Copyright

Copyright © 2026 Vedika Shinde. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.