Driving financial services technology forward

We specialize in serving the financial services industry, with an emphasis on banking, insurance, wealth management, lending, and fintech.

We specialize in digital design and engineering for financial services brands, so you save time by working with a team that already understands your industry.

We integrate design and engineering. You can rely on us to seamlessly integrate the user experience, interface design, and engineering capabilities to ensure you aren’t designing screens you can’t implement or building technology no one can use.

We’re all about modernizing your existing software applications. Existing software applications have unique challenges. We can confront your biggest people, process, and technical challenges and won’t judge you along the way. We’ll approach your initiative based on the reality of your current circumstances as opposed to looking at it through an ivory-tower lens.

We reduce risk. From our very first conversation with you, we’ll work diligently to identify risks that stand in the way of your objectives and work creatively and aggressively to mitigate and prevent them. Examples: controlling release size, reusing existing software assets, aligning our interests with those of your technology stakeholders, interactive prototyping to clarify requirements, and weekly project status reporting. Also, and potentially most importantly, we think big but start small. We won’t force you to commit to a lengthy (read: risky) engagement in order to get started. We won’t ask you to sign off on a seven-figure initial budget. We get creative with small initial engagements in order to earn your confidence by delivering a quick win and then work with you to expand the relationship.

We have a culture of accountability. Our systematic, metrics-based culture of accountability motivates our team to keep the promises they make. Examples include our CAN DO core values and weekly tracking of our commitments kept.

We pride ourselves on being technically outstanding but don’t boast about it. We’ve handpicked every member of our team to serve you. There are no out-of-control egos here.

We adjust around you and fit within your systems. Including within our client’s Jira account, development environment, etc. so that you stay in control of your intellectual property.

We’ll never hold you hostage. By maintaining thorough documentation and readily helping with knowledge transfer, we make it easy for you to offboard us when the time is right.

We are fortunate to have worked with many wonderful clients in our 20+ year history. When it comes to answering this question, we think you should take their word for it, not ours.

“They were very transparent with everything from software development to execution. Some of us didn’t understand what went into developing software, the problems that could come up, issues that could hold things up, and costs”

“Praxent was my first choice. I felt like they would be a group of advisors that would be an extension of our team. Praxent wouldn’t have needed a lot of hand-holding. Their price was higher but you get what you pay for. Praxent had a technical understanding and track record.”

“Praxent understood our business. They had experience working with one of our competitors. Praxent demonstrated their expertise. They understood what we wanted as a whole. Praxent did not try to upsell us.”

“[They have the] ability to engineer at every level of the company.”

“They were really interested in WHY we needed help.”

“Praxent opened our eyes to things that we never thought of before. They showed us how to make our applications more efficient.”

“They’re really knowledgeable. Each member of Praxent’s team is really impressive. They’re leading us. They came to us with suggestions and they’re guiding us. It’s been a very enjoyable experience.”

“Praxent understood us and what we wanted to do on a personal level.”

“Praxent provided us with a honest assessment of our needs.”

“Whether we agree or not, they explain everything and are very willing to listen.”

Check out our case studies page and Clutch reviews for more about how we are to work with.

Praxent has a team of over 120. Our delivery team is spread across four disciplines: engineering, product design, project management, and client services. In addition, we have in-house recruiting, operations, and marketing personnel.

We have worked remotely with geographically distributed teams since 2008. Our team members are distributed between Austin, Texas; Raleigh-Durham, North Carolina, and more; and throughout Latin America, including Mexico, El Salvador, Colombia, and beyond.

Our developers are located in Texas, North Carolina, and throughout Latin America. Since 2010, our hiring approach has been to source and hire the very best engineering talent we can find regardless of location.

In our 20+ year history, our experience has taught us that English proficiency (advanced level at least) and time zone overlap are non-negotiable as a baseline in order to ensure the effectiveness of the teams we deploy.

We begin our projects with a kickoff, which can be conducted in person or via video conference. We can usually start a new project within two weeks of your go-ahead, sometimes faster if desired.

Our rates range from $59 to $240 per hour depending on the role and engagement length.

Any work we do for you is performed on a work-for-hire basis, meaning you own the rights to it.

In order to speed your progress and save your budget, we offer “accelerators,” such as reusable boilerplate codebases that set the foundation for your web or mobile application and keep your team from having to recreate the wheel on commonplace functionality such as user authentication. If this is of interest, we can grant a permanent license for you to use and modify these.

The best way to ensure your app or software development project doesn’t go over budget is to accurately estimate the cost to build. If the estimate is too low, you could end up with an initiative that can’t pay for itself or is never finished.

We follow these three steps to ensure your project doesn’t go over budget:

1. Prioritize features and clearly define the initial release.
2. Create a clickable prototype with the features included in the initial release that you can test and validate before you move into development.

Accurately estimate cost and timeline. We create a detailed product roadmap that organizes the features and capabilities of the product by release timeframe.

You decide how often you’d like to meet with your team. Most of our clients have a meeting either weekly or twice weekly if design is underway.

You’ll meet directly with all of your team members, designers, developers, and a Delivery Lead who serves as your primary point of contact throughout the engagement.

Yes! There are two models where using your own project manager makes sense. One is for staff augmentation, where your team does all the planning and leadership. The other is in a hybrid model, where Praxent provides a counterpart project manager (we call them Delivery Leads) to manage Praxent’s people in partnership with your own.

Your software application is one of your biggest business assets. It’s our job to empower you to take it over, manage, and maintain it if and when it becomes appropriate for you to do so.

We do this by providing evolutionary documentation with every release. We deploy the source code to a repository that you own. We create videos to explain and demonstrate the key details of the build and deploy process. We provide detailed guidance and training. And, when the time is right, we willingly remove ourselves from the deploy process so you can own and control it.

We always aim to meet new clients where they are in the software development lifecycle. If you’ve already done the work to create a prioritized roadmap, we’ll be happy to start with design. If you’ve already done UX/UI design or it’s not required for this initiative, we’ll be happy to launch right into architecture, engineering, and/or maintenance.

In most cases, our answer is modernize; however, there are cases where we recommend a ground-up rebuild.

A rebuild might be appropriate when:

• Your existing system can no longer be maintained or continuously operated long enough for us to perform a modernization,
• the prospect of losing functionality the old system supported is less of a concern than the cost of supporting an old codebase that has become so technically complex that new feature development, or even system maintenance, is increasing at an exponential rate or
• the old architecture wouldn’t support a migration to a services-based architecture that would allow us to decouple the frontend from the backend in order to create a more competitive experience

While we can’t guarantee ROI, starting small helps to ensure we don’t overspend before your investments start returning value to your organization. In all new engagements, we apply an MVP approach and look for a way to minimize the initial release while still delivering business value. This reduces the risk to your organization of starting (because you’re not making a huge commitment) and accelerates the virtuous cycle of investing and harvesting a return.

Yes, absolutely. We often have a series of meetings at the start of a new relationship to ensure we have all of the situational awareness about your present circumstances, competitive factors, stakeholder interests, and organizational priorities. With this context, we will often partner with our project sponsor to present our recommendations in a way that builds consensus and organizational support.

A rough draft is a very helpful way to communicate the vision of a new software application and can significantly accelerate our early conversations. Design is required, however, to make your rough draft ready for engineering. As this blog post explains, incomplete software requirements is a leading cause of challenged and/or failed projects. Capturing an appropriate level of detail in the requirements we give to an engineering team is the most impactful way to ensure your success.

This excerpt from the essay titled Examining the “Big Requirements Up Front (BRUF) Approach” perfectly describes the importance of a thorough design step:

“More often than not what we identify as a changed requirement is really just an improved understanding of the actual requirement. People aren’t very good at predicting what they want. They are good at indicating what they sort of think that they might want, and then once they see what you’ve built they can then provide some feedback as to how to get it closer to what is actually needed. It’s natural for people to change their minds, so you need an approach which easily enables this.”

This post details five critical steps in writing requirements, including eliminating language ambiguity, understanding the business rationale, and identifying corner cases. The work of design plays a critical role in the process because it creates the right venue for you and your team to work through the nitty gritty details that have implications on both the software architecture and functionality.

Yes, absolutely. We place a big emphasis on working collaboratively with our clients no matter their team composition or preferred working style. When clients look to us to join or augment an existing team, we will often work with them on a Slack channel (or some other real-time chat platform), attend Agile sprint rituals via Zoom, and share design assets and prototypes in Sketch or Invision back and forth.

Benefits of this approach include:

• Leveraging your existing team’s subject matter expertise within your business and software domain while gaining an objective outsider’s perspective.
• Accelerating your progress against your roadmap with a flexible team that you can scale up and/or down as you need without managing the burden of hiring and managing full-time employees.
• Level up the agility, productivity, and client service of your internal team by adding experienced agilists who are accustomed to the fast-paced, client-centered environment of an agency.

We follow a human-centered design process. We start by learning as much as we can about your business and your users through a variety of methods such as collaborative workshops and user research. After that, we jump into design, where we generate ideas (sketches, mockups, prototypes) that we share with you and your users to solicit feedback and refine. Once we’re aligned on a design solution, we provide all the design assets necessary for development, and we (designers) join the Agile process to support engineers in design quality assurance, asset management, and translating the user’s perspective. As we continue to support development, we’re able to repeat this entire process for your other initiatives so we’re always ahead of the curve.

We work within a fixed-budget, scope-controlled engagement model. This allows us to give you the budget clarity and confidence your business needs as well as the scope flexibility that enables you to reprioritize or change direction as the environment changes. In most cases, design should represent about 15% of the total budget. Once we are underway, we will meet with you weekly to review an updated status report called CommandView® to ensure transparency and alignment with budget and scope.

There are two important considerations that impact whether we can fast track your release by parallel pathing our approach to design and development: 1) How well do we understand the requirements? and 2) Is there work to be done on the backend?

How well do we understand the requirements? Does the system already exist, and are we performing a modernization and/or rebuild? If the requirements are very well understood and we don’t have to rely on screen designs to lay the back-end groundwork, there is often an opportunity to run design and development in parallel.

For new product development engagements, however, our development teams rely on screen designs and interactive prototypes in addition to written requirements. In this case, starting the development workstream before design will result in rework. Sometimes it is necessary to make an exception (i.e., we are working to maximize the selling season, launch before a critical tradeshow or fulfill a commitment to a critical customer), and as long as the business is willing to pay for the speed gain (in the form of Technical Debt), we can help. To ensure we make the right decision, we will speak with you to evaluate the business opportunity of accelerating and the technical tradeoffs to ensure you are able to make an informed decision.

Is there work to be done on the backend? Assuming the business requirements are well understood—such as when we are modernizing an existing application—we can begin work on backend architecture and development without relying on the screen designs to fully comprehend the requirements. However, if Praxent is performing front-end development (e.g. building the interactive functionality of the user interface) it is often not productive or possible to parallel path front-end development and design.

The “customers” of design are your end users who will use the software, internal stakeholders who know the business requirements, and the engineering team who will build the functionality depicted by the UI/UX designs. We can’t say that a design is good enough until it has satisfied the questions and/or concerns of these three groups. Meeting (e.g. via Zoom) to demonstrate a design in the form of an interactive prototype is the most effective way to determine whether we are ready to move into development.

Beyond this, our designers employ a number of strategies—from time boxing their work to writing down and referring to the design principles of a project to participating in team design reviews to help them balance quality with speed.

Yes, we have both dedicated and cross-disciplinary user researchers on our team who work with clients to deliver customized research projects. Depending on your objectives, we will formulate a carefully sized research plan that gives us enough data to inform your decisions while not prolonging your decisions with analysis paralysis.

We can deliver a variety of research deliverables including usability testing, validating a design hypothesis, and/or identifying points of friction in the customer journey.

Absolutely. User research is THE core activity to user experience (UX) design. We conduct the research that surface important KPIs: time on task, VOC (voice of customer), unmet needs, usability benchmarks, error frequency. We also conduct user research to inform design principles, experience visions, feature prioritization, product roadmap, customer journeys, jobs thinking.

• Reduces long-term costs (build right the first time)
• Helps identify patterns of behavior
• Surfaces unique opportunities for product differentiation
• Builds product-specific design principles
• Foundational to designing products for real people and their circumstances
• Bridges gaps between the company and its customers
• Serves as the voice of the customer
• Can be used as a sales/marketing tool because users feel heard
• Helps to prevent design debt
• Helps validate ideas and designs before development
• Reduces long-term costs
• Leads to innovative solutions
• Serves as communication/alignment tool (“75% of our users are saying/doing X”)
• Gives you the “why” behind analytics (bounce rate, feature usage, etc.)

We have been practicing Agile methodologies since 2009, including Scrum and Kanban, depending on the stage of the project. Because we work with clients that have fixed budgets, we employ a fixed-budget, scope-controlled engagement model. With this structure, we can commit to delivering business objectives, not specific deliverables, which gives you the confidence of a fixed budget without the constraints of a fixed scope.

Because we do a mix of new product development as well as modernization of existing software, we work within a lot of different environments and domains. Below is a list of the most common technologies:

• Front-end technologies like React, Vue, Angular
  Back-end technologies like Microsoft .NET, Java, Python, NodeJS, PHP.
• Mobile technologies like React Native, Flutter, iOS, Android, Xamarin.
• Database technologies like MySQL, MongoDB, MSSQL.

Visit this page for a full listing of the technologies in our wheelhouse.

For web applications, we typically recommend React on the frontend with .NET Core or NodeJS on the backend.

We often build mobile applications using React Native in order to take advantage of its cross-platform benefits and the simplicity and cost savings of maintaining a single codebase.

Visit this page for more about how we recommend front-end development technologies.

Our developers are located in Texas, North Carolina, and throughout Latin America. Since 2010, our hiring approach has been to source and hire the very best engineering talent we can find regardless of location.

In our 20-year history, our experience has taught us that English proficiency (advanced level at least) and time zone overlap are non-negotiable as a baseline in order to ensure the effectiveness of the teams we deploy.

Because we serve clients in a variety of circumstances and industries, we tailor our security practices to each client and can detail them in an Information Security Policy tailored to your specific requirements. The following lists common practices described in such a policy document:

• Access Control Policy including background checks for employees, onboarding/Offboarding Compliance Procedures, SSO+2FA Required, VPN-Based Access, and Limited/Restricted Production Access.
• Logging and Monitoring Policy including Application Logging with SaaS Integration, Access Grant/Revoke Logging, Scheduled Access Audits, and Penetration Testing Scans.
• Vendor Management Policy including a Vendor Review/Approval Process and periodic vendor reviews.
• Business Continuity and Disaster Recovery Plan including infrastructure (hosting, application, and database) backup and recovery with incident response plan.

Yes we are, we received our certification in 2023.

No, and in most cases we recommend against it. You typically don’t want the same engineer who wrote a feature also being responsible for deploying that feature. This can increase your risk of releasing new features before they have been sufficiently tested and increases your risk of unauthorized access to sensitive customer information. Therefore, separation of development, testing, staging, and production environments is an important practice of a mature engineering team. If your team isn’t structured this way, we can help.

Yes, we often join existing development teams. This model allows our clients to rely on us to fill a specialized skill gap (e.g. often on the frontend), accelerate development velocity for an upcoming deadline, or act as a player/coach to level up the agility of an existing team.

In these cases, we recommend that our engineers join with yours for all of the Agile Sprint rituals and/or project meetings – usually daily – while working closely together within the same codebase repository (E.g. Azure DevOps Server, GitHub, etc.) and within the same collaboration environment (E.g. Slack, Microsoft Teams, Zoom, etc.)

We kick off every project with scalability and extensibility in mind. Scaling has to do with supporting higher volumes of users and data, while extensibility corresponds to how readily new, previously unimagined features, can be added.

Here’s how we do it.

Scalability:

A scalable application begins with good infrastructure, which can make or break your ability to readily scale.

Your frontend and backend scale at different paces—oftentimes, the backend and database need to scale long before your frontend does. By building and deploying your frontend and backend separately, we can maximize performance upgrades exactly where you need them, resulting in efficient scaling with no wasted spend.

In addition, there are a suite of “micro-techniques” we can apply to delay and/or nullify the need for scaling. Such strategies include caching (network and server-side), image optimization, microservices, asynchronous programming, database factories, and many more.

We’ll be there every step of the way to ensure your application scales with your growing consumer needs.

Extensibility:

An application is most extensible when the developers who did not write the code can readily ramp up to the codebase(s) and contribute new features. So extensibility is a lagging indicator of good code quality. Good code quality generally can be summed up as an equal balance of the following two attributes: self-documenting and “do-not repeat yourself” (DRY).

• Self-documenting code is easy to read and understand to any developer without extensive documentation to explain what the code is attempting to perform.
• DRY code enables teams to have reusable components, which means your applications can continue to grow at exponential speed without exponential cost.

These attributes counterbalance each other. Here’s how we ensure our teams are striking that balance:

1. Code standards: Each new hire must meet the rigorous standards we’ve defined for writing clean code. Our applicant-to-hire ratio is 0.38%, meaning we really do hire just the top 1% of talent. The leading indicator of a strong candidate is their command of SOLID principles, a top framework for defining code quality standards.
2. Boilerplates: We’ve established, as a result of decades of development, a large volume of boilerplates that have our best practices and code standards built into them. This ensures our developers implement the strategically important technical concepts we’ve identified as “must have” for good extensibility.
3. Strongly typed languages and linters: We choose strongly typed languages where possible and opt-in to strongly typed supersets where not possible (i.e., Flow on Javascript) to ensure, from the moment it is written, our developers’ code quality checks itself for any runtime errors. We also enable linters on our projects to enforce our agreed-upon code standards. This helps the code stay clean, performant, efficient, and most of all consistent, making it easy for any other developer to contribute.
4. Code review process: Each time a developer wants to contribute code to the project, they must have at least one developer review their code as a sanity check to ensure we’re meeting our own code standards. While linters and strongly typed languages catch about 80% of potential issues, this final check is the last step in verifying we are enforcing standards.
5. Automated testing: Prior to being deployed to your customers, code must go through an automated test suite. This step verifies that the application is still working as it was intended. While this can be accomplished with human testing, automated testing is more efficient and guarantees results 100% of the time.

Yes, absolutely. The right DevOps setup for your team can significantly improve team productivity and product quality. It can also make it possible to onboard new engineers in a more efficient and methodical way. However, the Goldilocks Rule applies. An over-engineered or overly complex DevOps process can be overkill, whereas a nonexistent process can spell disaster once an application is in production.

Whether you need help to streamline the way your repository is structured, need to provision and manage multiple environments, or would like to work toward automated build, testing, and deployment, we will conduct an assessment of your existing practices and work with you to level up where needed.

Yes, after the development work is done, Praxent can perform ongoing maintenance, upgrades, and minor feature enhancements on your product to ensure its continued stability and performance. This is done under a follow-on agreement with a fixed cost per month that is a small fraction of your original investment.