ProjectHelm

What ProjectHelm is

ProjectHelm is an AI app builder for teams that write C#. You describe an app in chat and it generates a real ASP.NET Core MVC solution on .NET 10 with EF Core, rather than the React front end and hosted backend most AI builders produce. The company says the result is clean C# that your team opens in Visual Studio or Rider, audits and owns. The product comes from Stivan Technologies, whose registered office is in Hyderabad, Telangana, India.

What you build and how

The home page numbers the loop from proposal through build, publish, deploy and sign-up to billing. The assistant never edits the app silently. Each AI proposal arrives as a diff of added lists, changed fields or new pages, and you Apply or Discard it. The site says the same rule holds whether the change is copy, a color or your data model. Page and color changes go live within seconds of Apply. Anything structural, such as a new feature or a new list, regenerates the source and goes out on a Publish click.

What gets generated is described as entities, permissions, an admin dashboard and workflows, "a genuine app, not a template filled in." The solution is a .slnx split into ordinary projects: Core.Models, Core.Dto, Core.Mappers and Core.Data, then Services.Abstract and Services.Implementation, then UI.Web with controllers, Razor views, Program.cs and a Dockerfile. The home page lists the pieces by file. AppModeGate.cs handles multi-tenant routing, Models/Entities.cs holds the POCO classes and DTOs, Data/AppDbContext.cs holds the EF Core mappings, WorkflowEngine.cs runs automations and triggers, and MetricService.cs does calculations and live KPIs. The headline feature list also names formula metrics and event triggers.

Each app gets its own data layer. The generator supports SQLite, PostgreSQL, SQL Server, MySQL and Oracle. By default an app runs on SQLite in its own container volume, not a table in a shared schema. When you download the source or push to Git you can pick any of the 5, and the standard EF Core provider packages are configured for you. The FAQ describes 3 App Types. Website covers public landing pages and marketing. BusinessApp is a single-tenant internal tool. SaaS is multi-tenant software with customer workspace separation, where all database queries are scoped to the active tenant automatically. That range covers a business site, an internal tool or a customer-facing product from the same generator.

Each app ships with sign-in already working. Options are password, Google, two-factor or phone, with roles and permissions generated rather than stubbed, and every visitor's account is scoped to their own workspace. An admin dashboard comes with CRUD screens that have search, filtering, sorting, paging, CSV import and export, and validation wired to your rules. The home page also mentions Cloudflare R2 storage for files, so uploads are not limited by container disk.

Publishing is container-based. On Publish, the FAQ says ProjectHelm compiles the C# solution, packages an optimized Docker container and starts it behind an automated reverse proxy with automatic SSL/TLS and isolated SQLite storage. You get a yourapp.projecthelm.in subdomain with HTTPS from the first build. To use your own domain you point a single CNAME record at it, and the guide says this needs no redeploy. DNS record, Let's Encrypt HTTPS and the reverse proxy are provisioned automatically.

On the way out, you can download the complete .slnx or push to GitHub, GitLab or Bitbucket. The FAQ says the export is sanitized: hosting tokens, incident reporters and credentials in appsettings.json are blanked and in-container platform hooks are decoupled. The site stresses that there is no proprietary runtime, no ProjectHelm SDK that your controllers inherit from and no DSL in place of C#.

What the pages say about cost, limits and support

Billing is prepaid credits, and one credit is one rupee. Every workspace starts with 200 free credits and the site says there is no subscription and nothing to cancel. You pay for the AI you use and a small daily rate while the app is live.

• AI messages are metered per reply on the work involved. Most everyday changes cost a handful of credits, and the exact cost shows under every reply.
• Hosting is 7 credits per day for a live app. Dedicated container storage is 2 credits per 50 MB per day, and it is charged even while the app is offline to preserve the volume.
• Stock photos are free, a picture generated to order is 2 credits, page edits are free and a full rebuild of the app is 30 credits.
• Previews, team sharing and network bandwidth cost nothing.

Credit packs listed are Starter at 399 rupees or $5 for 500 credits, Growth at 1,499 rupees or $18 for 2,000 credits, and Pro at 3,999 rupees or $48 for 6,000 credits. Checkout runs through Razorpay and Stripe, with tax invoices and history built in. The company warns you 10 days before credits run low, and a live app stays up for 7 more days after the balance runs out, with nothing deleted. A credit policy page explains the rules.

For support the footer lists a support portal and a support email, plus documentation and guides. It also links a Data Processing Agreement, a Source Control and Export Policy and a Credit Policy. The pages state no compliance certifications and no customer or user counts.

Who it suits and who it does not

The guide spells out the audience: a team that maintains C# and will own the app a year from now. If you are a .NET shop, a React single-page app on a hosted Postgres backend becomes a second stack and a second deployment story. The site also has a guide for .NET freelancers and agencies, which fits agency work where a client's own developers inherit the code. A solo founder with an internal tool or a SaaS idea can use the 3 App Types and the built-in tenancy, billing in rupees or dollars, and an app that lives on a subdomain from day one.

The company is direct about where it does not fit. Its own guide says that if your team writes TypeScript, wants a marketing site or a rich single-page interface, or needs a clickable prototype this afternoon that nobody will maintain, the JavaScript-first tools are the better choice. A few other caveats follow from the pages. Hosting is on ProjectHelm's own container platform, and the guide calls that "a commercial relationship" because you pay a daily rate while the app runs. Storage is metered by the megabyte, so a file-heavy app should read the credit policy first. The pricing page does not say how many credits a typical build uses, so budgeting from the pages alone is guesswork. Whoever maintains the generated project needs C# skills, since that is the point of the output.