Packaging architecture, security review, compliance standards, if the technical foundation isn't clear, products stall. We take your concept from idea to a certified, market-ready AppExchange listing.
We take your product vision from prototype to AppExchange, building scalable, certified Salesforce apps with deep expertise in LWC, Apex, and managed packaging.

.png)































































































.png)
Apex, LWC, Flows, Custom Metadata, we build Salesforce apps architected for performance, upgrade safety, and long term maintainability, whether internal tooling or multi-tenant products serving thousands of orgs.
.png)
We prepare your package from the inside out, CRUD/FLS compliance, secure Apex patterns, Locker Service compatibility, full documentation. Fewer review cycles, faster approval, earlier market entry.
.png)
Visualforce or legacy Aura holding you back? We migrate to LWC, restructure outdated codebases, and bring your architecture to current platform standards, improving performance and making your product easier to extend.
.png)
REST APIs, Platform Events, Change Data Capture, async processing, we build secure, scalable integration layers that work reliably across every subscriber org your product lands in.
.png)
Offline support, real-time data access, field-optimized interfaces, built for users who don't work from a desk, delivering a consistent experience in the office or on the move.
.png)
CI/CD setup, automated regression testing, version control, controlled deployments, every Salesforce release handled proactively so your app stays stable, compliant, and competitive on AppExchange.
Let's map out your implementation in a free 30-minute strategy call. No pressure. Just clarity.
Book a Call.png)

Packaging architecture, security review, compliance standards, if the technical foundation isn't clear, products stall. We take your concept from idea to a certified, market-ready AppExchange listing.
.png)
Legacy Visualforce, outdated Aura, ageing codebases, they limit what your product can become. If your app is hard to maintain or losing ground to modern competitors, we modernize the architecture and restore momentum.
.png)
Broken syncs, silent data errors, failed transactions, they erode customer trust fast. We rebuild your integration layer with the resilience, error handling, and field-level accuracy enterprise buyers expect.
.png)
If your teams are working around platform limitations instead of through them, custom development closes the gap, building exactly what your business needs within the Salesforce ecosystem.
.png)
Governor limits, bulk failures, degraded performance as your customer base grows, we redesign your processing architecture with async patterns and bulkification strategies built for any volume.
.png)
Three platform updates a year means three chances for something to break. Without structured release management, stability is always one update away from a support crisis. We handle it, proactively.
.png)
We write compliance in from day one, proper data access controls, Lightning-safe components, automated vulnerability checks throughout development. By submission, your package is already review-ready.
.png)
Modular, service-layered architecture that handles cross-object dependencies, advanced automation, and multi-step approvals, without turning into an unmaintainable tangle. Organized, testable, ready to grow.
.png)
Bulk processing patterns, async job frameworks, query optimization, every solution designed with governor limits in mind so your app runs reliably whether it's processing hundreds of records or hundreds of millions.
.png)
Error handling, retry logic, real-time event processing, we build integration architectures that communicate accurately and consistently with every external system, on day one and day three hundred.
.png)
We progressively migrate Visualforce, legacy Aura, and outdated Apex to current platform standards, preserving the functionality your customers depend on while eliminating the debt that's been slowing you down.
.png)
Automated regression testing, structured version control, release impact assessments, every platform update evaluated, tested, and deployed safely. No surprises, no breakages, no scrambling.
We want to get to know you and your organization, so we listen. Rest assured that you’ll be heard, supported, and empowered throughout projects and beyond.
.png)
Client satisfaction that speaks for itself, earned across every engagement, without exception.
Successful Salesforce implementations spanning startups to global enterprises, across industries and time zones.
Platform specialists, not generalists. Deep Salesforce expertise across every cloud and product family.
Real, active credentials across every Salesforce cloud, not a one-time badge, continuously renewed as the platform evolves.
Car Trackers ditched manual FedEx portal workflows by integrating Astonous Ship into Salesforce — automating label creation, customer emails, and shipment tracking for every DMV paperwork transaction.



CLS Brands partnered with Astonous to launch a Salesforce Digital Experience Portal, giving suppliers real-time visibility into orders, shipments, and inventory while dramatically reducing internal support workload.



Michael Malul partnered with Astonous to implement a full Salesforce Sales Cloud solution, transforming distributor onboarding, invoicing, shipping, and inventory into one seamless, automated operation.


Discover how our solutions have transformed businesses through innovative technology and dedicated support.
A Salesforce ISV app is a reusable product built for Salesforce customers. It may extend Sales Cloud, Service Cloud, Experience Cloud, Revenue Cloud, Data Cloud, Agentforce, or another Salesforce product.
Unlike a customer-specific Salesforce implementation, an ISV app is designed to be installed and used across multiple Salesforce organisations.
A custom Salesforce solution is normally built for one company and its specific business processes.
A Salesforce ISV app is a product built for multiple customers. It must account for different Salesforce configurations, security models, editions, data volumes, and business processes. It also requires packaging, licensing, installation, upgrades, documentation, and customer support.
Yes. We can help take a Salesforce app from an initial idea to a production-ready product.
The first step is usually a product discovery exercise where we define:
The outcome is a practical product roadmap rather than a large list of features without clear priorities
Before development begins, we recommend validating the problem with potential customers, Salesforce consultants, administrators, and industry specialists.
We can help assess competing AppExchange products, identify gaps, review the proposed value proposition, and define a focused first release. The goal is to confirm that customers will understand the problem and be willing to pay for the solution before making a significant development investment.
Most Salesforce ISVs should begin with a focused minimum viable product.
The first version should solve one important customer problem well and include enough functionality to demonstrate its value. Additional workflows, integrations, analytics, and industry-specific features can be introduced after receiving feedback from early customers.
This reduces development risk and helps the product reach the market sooner.
You can begin product planning and development before completing the full AppExchange partner process.
However, commercial distribution through the Salesforce ecosystem involves partner onboarding, business approval, the applicable partner agreement, security review, and AppExchange publishing activities. We can help you understand the technical steps, while final commercial and programme decisions remain between your company and Salesforce.
Yes. We can help prepare the technical and product information needed during Salesforce ISV onboarding and business approval.
This may include:
Salesforce makes the final decision on business approval and partner agreements.
Commercial AppExchange products are commonly distributed using a managed package because managed packages support versioning, upgrades, namespaces, and protection of managed components.
For new managed applications, Salesforce currently recommends second-generation managed packaging, commonly known as managed 2GP. The correct approach still depends on the application’s architecture, metadata requirements, dependencies, and existing package history.
First-generation managed packaging, or 1GP, is managed mainly through a packaging organisation.
Second-generation managed packaging, or 2GP, follows a source-driven development model and works more naturally with Salesforce CLI, version control, scratch orgs, and automated build processes.
For a new application, we normally evaluate managed 2GP first. For an existing 1GP application, we review the current package and customer installations before recommending any migration.
Yes. We can assess an existing first-generation managed package and determine whether moving to second-generation packaging is appropriate.
The assessment includes package components, dependencies, namespace, version history, extension packages, customer installations, build process, and release strategy. Salesforce now provides a managed package migration path, but it must be planned carefully because existing subscribers and future upgrades need to be protected.
Often, yes, but code written for a single Salesforce org usually needs changes before it is suitable for a commercial managed package.
We review the existing solution for:
The goal is to make the application configurable and reliable across different customer organisations.
A Salesforce ISV application may include:
The architecture depends on the business problem and the Salesforce products the application supports.
Yes. We can help develop Salesforce applications that use or extend Agentforce.
This may include agent actions, Apex actions, Flow-based actions, prompt templates, data grounding, external integrations, configuration screens, and managed package components.
We also review how the agent accesses customer data, what actions it can perform, how permissions are enforced, and how the product will behave across different subscriber organisations.
Yes. A managed package can connect Salesforce with an external platform through APIs, webhooks, middleware, platform events, named credentials, external credentials, or other supported integration methods.
The design must consider:
We design the integration so each customer can configure their own credentials without exposing sensitive information.
A commercial Salesforce app should not assume that every customer follows the same process.
We use configuration options such as custom metadata, permission sets, mapping screens, feature settings, templates, and administrator-controlled rules. This allows customers to adapt the application without changing managed code.
Good configurability reduces customer-specific development and makes future upgrades easier.
Security is considered from the beginning of the product, not only when the application is ready for AppExchange security review.
We review areas such as:
We also use Salesforce security-scanning tools and perform manual reviews before submitting the application.
The AppExchange security review evaluates whether an application follows Salesforce security requirements and protects customer data appropriately.
The review may include managed package components, external applications, APIs, connected applications, authentication flows, mobile applications, and other systems used by the product.
A product generally needs to complete the applicable security review before its public AppExchange listing can be published.
No development company can guarantee Salesforce’s final security review decision.
We can significantly improve readiness by following secure development practices, reviewing the application architecture, running Salesforce Code Analyzer, testing external endpoints, preparing documentation, and resolving known issues before submission.
If Salesforce reports findings, we can help analyse and fix them before resubmission.
Yes. We can review the security report, reproduce the findings, and prepare a remediation plan.
Common work may include fixing permission enforcement, injection vulnerabilities, insecure data storage, authentication weaknesses, outdated libraries, missing documentation, or problems in external endpoints.
We can also review the full application rather than addressing only the reported examples, since the same issue may exist in other parts of the codebase.
The exact requirements depend on the application, but a submission may require:
A complete and properly configured submission helps avoid unnecessary review delays.
A focused Salesforce application may take a few months to design, develop, test, package, and prepare for release.
The timeline depends on:
After discovery, we provide a phased plan with milestones, responsibilities, and expected deliverables.
The cost depends on the application’s scope, architecture, integrations, packaging complexity, security requirements, and the condition of any existing codebase.
A simple application with a focused workflow will cost less than a platform product supporting multiple Salesforce clouds, external systems, editions, and customer configurations.
We normally begin with discovery and provide an estimate for the minimum viable product, followed by optional phases for additional features.
Salesforce programme fees, security review fees, listing charges, and revenue-sharing obligations are separate from Astonous development fees and should be confirmed directly with Salesforce.
Yes. We can help you evaluate common models such as:
The final model should reflect the value delivered, expected customer size, cost to serve, Salesforce commercial terms, and how easily the licence can be managed technically.
Yes. We can help connect the managed package with the License Management App and design the required licensing process.
This may include trial licences, active licences, expiration dates, seat counts, customer information, and internal automation for onboarding or renewals.
Where the application requires additional feature controls, we can also build product-level entitlement management.
Yes. Depending on the product and go-to-market approach, customers may be offered an installable trial, a guided demonstration, a test drive, or a dedicated trial organisation.
We can help prepare the trial experience, sample data, onboarding instructions, configuration steps, and follow-up process. The trial should allow a prospect to understand the product’s value without requiring a large implementation effort.
Yes. We can support the technical and product content required for an AppExchange listing.
This may include:
Final listing approval and publishing are managed through Salesforce’s partner and publishing processes.
Managed package testing requires more than testing the application in the development environment.
We test:
Where practical, automated tests and repeatable build processes are included in the development workflow.
We design the application for Salesforce’s multi-tenant environment from the beginning.
This includes bulk-safe Apex, efficient queries, asynchronous processing where appropriate, controlled callouts, selective data access, scalable automation, and testing with realistic data volumes.
We also review how the managed package will interact with automation already present in a customer’s Salesforce org.
Yes. We can review the complete product experience, including installation, setup, navigation, configuration, daily usage, error messages, and customer documentation.
Improvements may include Lightning Web Component redesign, simplified setup screens, guided configuration, clearer validation, fewer manual steps, better mobile support, or more consistent Salesforce design patterns.
Yes. We can take over a product that was built by an internal team, freelancer, or another Salesforce development company.
We normally begin with a technical assessment covering:
After the assessment, we propose a transition and release plan that reduces risk for existing customers.
Yes. We work with existing Salesforce ISVs that need help maintaining, improving, or expanding a listed application.
Support may include:
New functionality is released through managed package versions.
Depending on the package, release, and customer requirements, customers may install an upgrade themselves or the ISV may use an approved push-upgrade process. Each release should be tested against earlier supported versions and existing customer data.
We help plan package ancestry, versioning, backward compatibility, deprecation, upgrade scripts, and customer communication.
Yes, but customer-specific work should be kept separate from the core managed package wherever practical.
Common approaches include:
This allows the main product to remain upgradeable while still meeting a customer’s specialised requirements.
Salesforce publishes three major platform releases each year. An ISV should review upcoming changes, test the application in preview environments, update affected components, and communicate any required customer actions.
We can manage release-readiness testing and resolve compatibility issues before the Salesforce update reaches customer production organisations.
Salesforce provides AppExchange partners with tools that can help understand package adoption and usage, subject to the applicable setup and Salesforce policies.
We can also design privacy-conscious product telemetry, error logging, feature adoption reporting, and health monitoring. The product should collect only the information needed and clearly respect customer security and privacy requirements.
Managed package code is protected, so troubleshooting must be designed into the product.
We use structured logging, clear error messages, support utilities, configuration checks, subscriber support capabilities, and controlled diagnostic information. When access is required, it should be granted by the customer and limited to the time and purpose needed.
Customer-funded product code and deliverables are owned according to the signed engagement agreement.
We recommend documenting ownership of:
Where practical, product assets should be maintained in accounts controlled by the ISV.
We can sign a mutual non-disclosure agreement before reviewing sensitive product information.
Access to source code, customer data, packaging organisations, and business documentation is limited to authorised team members. Repository permissions, credentials, and development environments are managed according to the agreed security process.
Yes. We can work as an offshore product-development team, a specialist managed-package team, or an extension of an existing Salesforce engineering organisation.
The engagement can cover architecture, development, testing, packaging, security review preparation, release management, and ongoing maintenance.
Customer communication, branding, intellectual-property ownership, working-hour overlap, and responsibilities are agreed before the engagement begins.
Building a Salesforce product is different from completing a single Salesforce implementation. It requires product thinking, secure architecture, managed packaging, release planning, customer configurability, and long-term platform maintenance.
Astonous combines Salesforce consulting experience with practical ISV product-development experience. We can support the full product lifecycle—from early discovery and managed package development to AppExchange preparation, customer onboarding, upgrades, and ongoing product growth.